, defined as
the SNR variation w.r.t. baseline under the requirement BLER=10-1.Please refer to RP-221858 for detailed scope of the WI on further NR coverage enhancements.
R1-2210782 Session notes for 9.14 (Further NR coverage enhancements) Ad-Hoc Chair (CMCC) (rev of R1-2210696)
R1-2208783 Work plan for Rel-18 WI on Further NR coverage enhancements China Telecom
R1-2208488 Discussion on PRACH coverage enhancements ZTE
Number of PRACH repetitions
· Proposal 1: One or more new configured SSB-RSRP thresholds can be introduced for different PRACH coverage levels, i.e., different number of PRACH repetitions.
· Proposal 2: The number of PRACH repetitions with 2, 4 and 8 is proposed for multiple PRACH transmissions.
Same beam or different beams
· Proposal 3: Multiple PRACH transmissions with same beam on the ROs associated with the same SSB should be supported for PRACH coverage enhancement.
· Proposal 4: Multiple PRACH transmissions with different beams on the ROs associated with the same SSB should be considered for PRACH coverage enhancement.
Resource for multiple PRACH transmissions
· Proposal 5: For preamble index in multiple PRACH transmissions bundle, keep the same preamble index or randomize the preamble index in group based on predefined rule.
· Proposal 6: Separated preamble index for multiple PRACH transmissions is needed to differentiate between the multiple PRACH transmissions and single PRACH transmission, or to identify the number of multiple PRACH transmissions, if legacy ROs are shared by multiple PRACH transmissions.
· Proposal 7: Separate ROs by shared legacy PRACH configuration with or without additional new parameters should be considered for the multiple PRACH transmissions.
· Proposal 8: Completely separating PRACH configuration for multiple PRACH transmissions from legacy PRACH configuration is not preferred.
· Proposal 9: Approach of multiple PRACH transmissions in the frequency domain is not recommended.
· Proposal 10: Multiple PRACH transmissions using multiple panels could be investigated.
RAR enhancements
· Proposal 11: RAR window starts after the last PRACH repetitions should be applied if single RAR is adopted for multiple PRACH transmissions.
· Proposal 12: Multiple RAR windows for multiple PRACH transmissions can be considered if gNB cannot have the knowledge about whether or not the UE is under multiple PRACH transmissions.
RA-RNTI
· Proposal 13: Single RA-RNTI is calculated based on RO for the last or first PRACH repetition.
· Proposal 14: UE should assume that multiple RA-RNTIs are calculated based on multiple ROs for the PRACH repetitions if RA-RNTI calculation is not based on a predefined single RO.
Others
· Proposal 15: Power ramping is applied in case of multiple PRACH transmissions with the same beam. The power should remain unchanged in case of multiple PRACH transmissions with different beams.
· Proposal 16: Multiple PRACH transmissions can be enabled during the PRACH re-attempts in case of transmitting power or number of PRACH retransmissions reaching a threshold.
· Proposal 17: If multiple PRACH transmissions is used in the initial access, the retransmission should use multiple PRACH transmissions too.
· Proposal 18: The coupling between PRACH repetitions, msg3 repetitions, and PUCCH repetitions for HARQ-ACK of Msg4 should be investigated.
· Proposal 19: The CFRA based multiple PRACH transmissions should be investigated.
· Proposal 20: Study potential coverage enhancements for PRACH in FWA scenario to address the demands from practical network deployment.
Decision: The document is noted.
R1-2208411 Discussion on PRACH coverage enhancements Huawei, HiSilicon
R1-2208575 Discussion on PRACH coverage enhancements Spreadtrum Communications
R1-2208671 Discussions on PRACH coverage enhancements vivo
R1-2208784 Discussion on PRACH coverage enhancement China Telecom
R1-2208846 PRACH coverage enhancements OPPO
R1-2208963 PRACH coverage enhancements CATT
R1-2209001 PRACH coverage enhancements TCL Communication Ltd.
R1-2209025 Discussion on PRACH Coverage Enhancement Fujitsu
R1-2209078 Discussions on PRACH coverage enhancement Intel Corporation
R1-2209116 PRACH Coverage Enhancement using Multi PRACH Transmissions Sony
R1-2209130 Discussion on PRACH coverage enhancements Panasonic
R1-2209159 Discussion on PRACH coverage enhancement NEC
R1-2209223 PRACH coverage enhancements Lenovo
R1-2209249 Discussion on solutions for NR PRACH coverage enhancement Mavenir
R1-2209272 Discussion on PRACH coverage enhancements xiaomi
R1-2209363 Discussion on PRACH coverage enhancements CMCC
R1-2209412 PRACH coverage enhancements ETRI
R1-2209415 Discussion on triggering multiple PRACH transmissions FGI
R1-2209521 Enhancements for PRACH coverage MediaTek Inc.
R1-2209608 Discussion on PRACH coverage enhancement Apple
R1-2209661 Discussion on PRACH repetition InterDigital, Inc.
R1-2209672 Discussion on PRACH coverage enhancement Ericsson
R1-2209759 PRACH coverage enhancements Samsung
R1-2209788 Views on multiple PRACH transmission for coverage enhancement Sharp
R1-2209803 Discussion on PRACH repeated transmission for NR coverage enhancement LG Electronics
R1-2209925 Discussion on PRACH coverage enhancements NTT DOCOMO, INC.
R1-2210013 PRACH Coverage Enhancements Qualcomm Incorporated
R1-2210165 PRACH coverage enhancements Nokia, Nokia Shanghai Bell
[110bis-e-R18-Coverage-01] – Nanxi (China Telecom)
Email discussion on PRACH coverage enhancement by October 19
- Check points: October 14, October 19
R1-2210318 FL Summary#1 of PRACH coverage enhancements Moderator (China Telecom)
Presented in Oct 13th GTW session
R1-2210553 FL Summary#2 of PRACH coverage enhancements Moderator (China Telecom)
R1-2210554 FL Summary#3 of PRACH coverage enhancements Moderator (China Telecom)
From Oct 18th GTW session
Agreement
For multiple PRACH transmissions with same beam, at least support to use same PRACH preamble during the multiple PRACH transmissions in one RACH attempt.
· FFS: whether different preambles can be utilized in different PRACH transmissions during the multiple PRACH transmissions in one RACH attempt.
Agreement
For multiple PRACH transmissions with same beam, at least ROs located at different time instances can be utilized for the transmissions.
· FFS: whether/how the starting RB of ROs can be different at different time instances for multiple PRACH transmissions.
· FFS: whether/how multiple PRACH transmissions located in the same time instance, e.g., for UEs with multiple Tx chains.
Agreement
For multiple PRACH transmissions with same beam, for RAR monitoring, consider the following options.
· Option 1: One RAR window per each PRACH transmission, the RAR window follows the legacy design.
o FFS: RA-RNTI.
· Option 2: Only one RAR window for all of the multiple PRACH transmissions.
o FFS: the start position of the RAR window.
o FFS: RA-RNTI.
Final summary in R1-2210660.
R1-2210014 Power-domain enhancements Qualcomm Incorporated
On enhancements to reduce MPR/PAPR
· Proposal 1: For power-domain enhancements targeting MPR/PAPR optimization focus on the following class of waveforms:
o DFT-S-OFDM
o QPSK modulation
o Inner and outer RB allocations
o Small RB allocation (1-16 RBs)
· Proposal 2: Study non-transparent techniques that allow a 0-dB MPR waveform to be transmitted at a transmit power exceeding the maximum power associated with the UE power class.
· Proposal 3: Study sideband tone reservation as a non-transparent waveform shaping technique to transmit DFT-S-OFM waveforms at a higher transmit power.
o Sideband tone reservation is given in units of RBs
· Proposal 4: For evaluating the benefits of tone reservation, use legacy R17 PUSCH waveforms as a baseline, with the excess bandwidth included in the total allocated bandwidth.
· Proposal 5: Study FDSS with bandwidth expansion as a non-transparent waveform shaping technique to transmit DFT-S-OFM waveforms at a higher transmit power.
o Excess bandwidth is given in units of RBs
o DMRS and data symbols undergo spectrum shaping
· Proposal 6: For FDSS with bandwidth expansion, link-level performance evaluations are required to assess the overall coverage gains. In particular, evaluate the impact of (a) the amount power spent in the excess bandwidth region and (b) gNB receiver handling of the excess bandwidth when receiving the PUSCH transmission for further processing.
· Proposal 7: For FDSS with bandwidth expansion, evaluate the impact of gNB not knowing the pulse shaping filter used by the UE (but aware of bandwidth expansion).
On enhancements to realize high power uplink transmissions in CA and DC
· Proposal 8: To facilitate higher power transmission in CA and DC scenarios, introduce signalling mechanisms between UE and gNB focused on
o increasing awareness of power or energy budget available at the UE for each carrier/band,
o aiding the selection of the best band combination for UL CA, and
o aiding scheduling policy when UE is configured with multiple bands in UL CA, for e.g., selecting preferred carrier for servicing uplink, or adaptive load sharing across carriers.
· Proposal 9: Introduce signaling to allow UE to report aspects related to power management and RF exposure.
· Proposal 10: Enhance the current power headroom reporting framework to allow a user to also report P-MPR (via MPE field) for FR1 carriers.
· Proposal 11: Enhance the current power headroom reporting framework to allow a user to report power headroom for a carrier that is configured for downlink but not for uplink (i.e., no active uplink BWP).
· Proposal 12: Introduce MAC-CE signaling to allow UE to report energy headroom for each of the bands in a CA/DC configuration given to the UE.
o FFS: signaling details, including, periodicity, reporting triggers, relation to PHR, how to handle multiple bands, reference power, etc.
Decision: The document is noted.
R1-2208412 Discussion on coverage enhancement in power domain Huawei, HiSilicon
R1-2208489 Discussion on power domain enhancements ZTE
R1-2208576 Discussion on power domain enhancements Spreadtrum Communications
R1-2208672 Discussions on power domain enhancements vivo
R1-2208847 The study of power domain enhancements OPPO
R1-2208964 Discussion on power domain enhancements CATT
R1-2209026 Discussion on power domain enhancements for CA/DC Fujitsu
R1-2209079 Discussions on power domain enhancement Intel Corporation
R1-2209224 Power domain enhancements Lenovo
R1-2209364 Discussion on power domain enhancements CMCC
R1-2209522 Discussion on power-domain enhancements MediaTek Inc.
R1-2209609 Discussion on power domain coverage enhancement Apple
R1-2209662 Uplink power enhancements InterDigital, Inc.
R1-2209673 Power Domain Enhancement Evaluation Methodology and Schemes Ericsson
R1-2209760 Power domain enhancements Samsung
R1-2209789 Power domain enhancements for Rel-18 CovEnh Sharp
R1-2209926 Discussion on power domain enhancements NTT DOCOMO, INC.
R1-2210166 RAN1 impacts for power domain enhancements Nokia, Nokia Shanghai Bell
[110bis-e-R18-Coverage-02] – Marco (Nokia)
Email discussion on power domain enhancements by October 19
- Check points: October 14, October 19
R1-2210322 FL summary of power domain enhancements (AI 9.14.2) Moderator (Nokia/Nokia Shanghai Bell)
R1-2210323 FL summary #2 of power domain enhancements (AI 9.14.2) Moderator (Nokia/Nokia Shanghai Bell)
From Oct 13th GTW session
Agreement
The following work split principles will be adopted in RAN1 for power domain enhancement throughout Rel-18 from RAN1 perspective and send LS to RAN4 in this meeting:
· RAN1 performs link level simulations of candidate solutions for power domain enhancements to study at least the SNR variation, PAPR/CM, and EVM, brought by each solution.
o Transparent MPR/PAR reduction solutions can be considered as a benchmark for studying the performance of non-transparent solutions.
· RAN1 is not expected to perform RF simulations of candidate solutions for power domain enhancements
o Results of RF simulations can be included in RAN1 contributions
· RAN1 will assess RAN1 specification impact of candidate MPR/PAR reduction solutions
o A list of candidate solutions, including necessary parameters, from RAN1 perspective should be ready before the end of RAN1 #111, and should be included in an LS to RAN4.
· RAN1 understands that RAN4 is responsible for selecting the Rel-18 MPR/PAR reduction solution, if any.
R1-2210324 FL summary #3 of power domain enhancements (AI 9.14.2) Moderator (Nokia/Nokia Shanghai Bell)
Decision: As per email decision posted on Oct 18th,
R1-2210563 [Draft] LS on work split principles adopted in RAN1 for power domain enhancements Moderator (Nokia)
Decision: The draft LS R1-2210563 is endorsed in principle with modifying (‘RAN2’ should be ‘RAN4’ in “ACTION: RAN1 respectfully requests RAN2 to take the above into account in their future work.”). Final LS is approved in R1-2210674.
Conclusion
Sub-PRB transmission is de-prioritized for the study of MPR/PAR reduction solutions in Rel-18.
Agreement
The following spectrum extension options for frequency domain spectrum shaping with spectrum extension (FDSS-SE), are considered for studying MPR/PAR reduction enhancements in Rel-18:
· Option 1: Symmetric extension
· Option 2: Cyclic extension
· Option 3: Cyclic shift plus symmetric extension.
Agreement
The following design aspects of tone reservation (TR), are considered for studying MPR/PAR reduction enhancements in Rel-18:
· Sideband tone reservation size is expressed in integer units of RBs.
· FFS:
o Sideband tone reservation size
o Sideband tone reservation size determination
o Whether PRTs are added only to data or also DMRS symbols
R1-2210325 FL summary #4 of power domain enhancements (AI 9.14.2) Moderator (Nokia/Nokia Shanghai Bell)
From Oct 18th GTW session
Agreement
For enhancements to realize increasing UE power high limit for CA and DC, RAN1 can study based on RAN4’s input
· Whether RAN1 enhancements to information exchange between UE and gNB are needed to improve scheduling and network performance when using higher power CA/DC.
o FFS how to realize such information exchange, e.g., signalling enhancement, and what is the spec impact.
Decision: As per email decision posted on Oct 19th,
R1-2210673 [Draft] LS on enhancements to realize increasing UE power high limit for CA and DC Moderator (Nokia)
Decision: The draft LS R1-2210673 is endorsed in principle. Final LS is approved in R1-2210739.
Agreement
DFT-s-OFDM is the target waveform for the study and, if applicable, the design of MPR/PAR reduction solutions in Rel-18.
Note: No doubt from RAN1 about the offline consensus “Results concerning the application of solutions for DFT-s-OFDM to CP-OFDM can be presented by companies in their contributions”.
Agreement
For power-domain enhancements targeting MPR/PAR reduction, study the following configurations for DFT-S-OFDM:
· At least pi/2-BPSK and QPSK modulation are considered
o FFS: other modulations, e.g., 16-QAM
· Any number of RB can be considered
· The starting RB of the allocation can be any RB in the BWP
o FFS:
§ Whether restrictions on the number of allocated RB or on the starting RB of the allocation are considered.
Agreement
At least the following candidate solutions for MPR/PAR reduction will be studied in RAN1.
• Frequency domain spectrum shaping w/ spectrum extension
• Frequency domain spectrum shaping w/o spectrum extension
• Tone reservation (which can only be w/ spectrum extension)
Decision: As per email decision posted on Oct 20th,
Agreement
The following design aspects of frequency domain spectrum shaping with spectrum extension (FDSS-SE), are considered for studying MPR/PAR reduction enhancements in Rel-18:
• Spectrum extension size is expressed in integer units of RBs.
• Both DMRS and data symbols undergo spectrum shaping
• FFS:
o Which extensions factor(s) to consider, where extension factor (α) is given by spectrum extension size / Total allocation size.
o Impact of shaping filter on FDSS-SE performance
o How to extend DMRS sequence to spectrum extensions, based on either the existing ZC-sequence DMRS or low-PAPR DMRS for PUSCH (FG 16-6c)
o How extension size is determined
Agreement
For link-level performance evaluation:
All considered solutions should be configured to operate with same amount of time-frequency resource and a same spectral efficiency, that is:
Note: it is understood that minor TBS variations across different waveform configurations can occur and are acceptable.
Agreement
For link-level performance evaluation, the performance of the considered MPR/PAR reduction solutions
is studied using at least the metrics included in the work split principles for
power domain enhancement agreed by RAN1 for Rel-18, for instance, but no
limited to, , defined as
the SNR variation w.r.t. baseline under the requirement BLER=10-1.
• FFS whether further definition or refinement of the metrics is needed
Note: metrics other than the ones included in the work split principles for power domain enhancement agreed by RAN1 for Rel-18 can be reported by companies.
Agreement
For link-level performance evaluation, companies are encouraged to report configuration details of the following aspects, when applicable:
• Shaping filter used for evaluating frequency domain spectrum shaping w/ and w/o spectrum extension (both the filter used at the transmitter and at the receiver should be reported, if the two filters are assumed to be mismatched).
• PRT generation algorithm used for evaluation tone reservation w/ spectrum extension.
• Design details and configuration of any transparent scheme used as benchmark
Agreement
For link-level performance evaluation of MPR/PAR reduction solutions involving the use of Tx filter, companies are encouraged to assume a Tx filter which fulfils a set of spectrum flatness requirements, e.g., existing RAN4 spectrum flatness requirements
For link-level performance evaluation of MPR/PAR reduction solutions involving the use of spectrum extensions or sideband, companies are encouraged to report whether/how the extended portion of the spectrum is handled by the receiver in the simulations.
R1-2210326 Final FL summary of power domain enhancements (AI 9.14.2) Moderator (Nokia/Nokia Shanghai Bell)
R1-2210167 Dynamic switching between DFT-s-OFDM and CP-OFDM Nokia, Nokia Shanghai Bell
o RB regions and associated MPR (i.e., DFT-s-OFDM is used when the PUSCH is scheduled in the outer/edge regions and CP-OFDM is used when the PUSCH is scheduled in the inner RB region),
o PHR limitation (i.e., DFT-s-OFDM is used when the latest PHR is sufficiently small, otherwise CP-OFDM),
o Total allocated RBs (i.e., DFT-s-OFDM is used when the total number of allocated RBs is sufficiently small, otherwise CP-OFDM).
· Proposal 8. RAN1 to study enhancements for power headroom reporting for assisting gNB on selecting a suitable waveform.
Decision: The document is noted.
R1-2208413 Discussion on dynamic waveform switching for coverage enhancement Huawei, HiSilicon
R1-2208490 Discussion on dynamic waveform switching ZTE
R1-2208577 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Spreadtrum Communications
R1-2208673 Discussions on dynamic switching between DFT-S-OFDM and CP-OFDM vivo
R1-2208785 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM China Telecom
R1-2208848 Supporting of dynamic switching between DFT-S-OFDM and CP-OFDM OPPO
R1-2208965 Dynamic switching between DFT-S-OFDM and CP-OFDM CATT
R1-2209080 Dynamic switching between DFT-S-OFDM and CP-OFDM waveform Intel Corporation
R1-2209117 Considerations on dynamic waveform switching for NR UL Sony
R1-2209160 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM NEC
R1-2209162 Discussion on dynamic waveform switching Panasonic
R1-2209205 Dynamic switching between DFT-S-OFDM and CP-OFDM InterDigital, Inc.
R1-2209225 Discussion on dynamic switching between DFT-s-OFDM and CP-OFDM Lenovo
R1-2209248 Discussion on solutions for NR dynamic switching between DFT-S-OFDM and CP-OFDM Mavenir
R1-2209273 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM xiaomi
R1-2209365 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM CMCC
R1-2209413 Dynamic switching between DFT-S-OFDM and CP-OFDM ETRI
R1-2209433 Discussion on Dynamic switching between DFT-s-OFDM and CP-OFDM Fujitsu Limited
R1-2209523 Discussion on dynamic switching between waveforms MediaTek Inc.
R1-2209610 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Apple
R1-2209674 Discussion on Dynamic UL Waveform Switching Ericsson
R1-2209761 Dynamic switching between DFT-S-OFDM and CP-OFDM Samsung
R1-2209790 Dynamic switching between DFT-S-OFDM and CP-OFDM for Rel-18 CovEnh Sharp
R1-2209804 Discussion on dynamic waveform switching for NR coverage enhancement LG Electronics
R1-2209927 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM NTT DOCOMO, INC.
R1-2210015 Dynamic switching between DFT-S-OFDM and CP-OFDM Qualcomm Incorporated
R1-2210115 Discussion on Dynamic switching between DFT-S-OFDM and CP-OFDM CEWiT
[110bis-e-R18-Coverage-03] – Paul (InterDigital)
Email discussion on dynamic switching between DFT-S-OFDM and CP-OFDM by October 19
- Check points: October 14, October 19
R1-2210431 Summary #1 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
R1-2210432 Summary #2 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
Presented in Oct 13th GTW session
Decision: As per email decision posted on Oct 16th,
Agreement
Dynamic waveform switching enhancement in R18 is only applicable to PUSCH channel.
R1-2210433 Summary #3 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From Oct 17th GTW session
Working Assumption
Support at least one of the following options for the dynamic waveform indication in R18:
· Alt 1: Indication from an UL scheduling DCI
o Alt 1-A: New field in scheduling DCI
o Alt 1-B: Reuse existing field in scheduling DCI
§ Alt 1-B-1: Explicit indication by repurposing field, e.g.
· Add one column to TDRA table
· Add one column to MCS table(s)
· Other solutions not precluded
§ Alt 1-B-2: Implicit determination from condition(s) on scheduling information, e.g.
· RA type, MSB of RA
· Number of RBs (below threshold or multiple of 2,3,5)
· Location of RB allocation within carrier and the associated MPR
· MCS below threshold
· Number of PUSCH repetitions (or whether PUSCH repetition is used) and/or TBoMS
· Number of DMRS CDM group(s) without data
· Precoding information and number of layers
· SRI
· Condition over multiple types of scheduling information
· Other types of scheduling information not precluded
o Indicated waveform applies at least to the scheduled PUSCH transmission
§ FFS: Whether it also applies to subsequent transmissions, and of which type
o FFS: DCI formats can contain the indication
o FFS: Indication applies only if condition(s) are satisfied (e.g. PDCCH occasion, /RNTI, /Search space of the scheduling DCI, latest PHR reported by the UE, etc.)
· Alt 2: Indication from a non-UL scheduling DCI
o FFS: DCI formats that can provide the indication (e.g. Downlink DCI, UE-group common DCI)
o FFS: Types of subsequent transmissions to which indication is applicable
From Oct 18th GTW session
Agreement
To study and if necessary, specify, enhancements to assist the scheduler in determining waveform switching, such as:
· Reporting power headroom related information
· Other solutions are not precluded
Decision: As per email decision posted on Oct 21st,
Agreement
Dynamic waveform switching enhancement in R18 is applicable to PUSCH scheduled by DCI format 0_1 or 0_2 in PDCCH with CRC scrambled with C-RNTI, MCS-C-RNTI, or CS-RNTI with NDI=1.
Final summary in R1-2210749.
Please refer to RP-221858 for detailed scope of the WI on further NR coverage enhancements.
R1-2212851 Session notes for 9.14 (Further NR coverage enhancements) Ad-Hoc Chair (CMCC)
Endorsed and contents incorporated below.
[111-R18-CovEnh] – Nanxi (China Telecom)
To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2210879 Discussion on PRACH coverage enhancements Huawei, HiSilicon
R1-2211033 Discussions on issues of PRACH coverage enhancements vivo
R1-2211047 Discussion on PRACH coverage enhancements ZTE
R1-2211087 Discussion on PRACH coverage enhancements Fujitsu
R1-2211185 PRACH coverage enhancements CATT
R1-2211254 Discussion on PRACH coverage enhancements Spreadtrum Communications
R1-2211350 Discussion on PRACH coverage enhancements xiaomi
R1-2211423 Discussions on PRACH coverage enhancement Intel Corporation
R1-2211474 PRACH coverage enhancements OPPO
R1-2211537 Discussion on PRACH coverage enhancement China Telecom
R1-2211541 PRACH coverage enhancements TCL Communication Ltd.
R1-2211568 PRACH coverage enhancements ETRI
R1-2211573 PRACH coverage enhancements Lenovo
R1-2211592 Discussion on PRACH coverage enhancements Panasonic
R1-2211595 PRACH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2211630 PRACH Coverage Enhancement using Multi PRACH Transmissions Sony
R1-2211705 Discussion on PRACH coverage enhancements CMCC
R1-2211711 Discussion on PRACH coverage enhancements InterDigital, Inc.
R1-2211837 Discussion on PRACH coverage enhancement Apple
R1-2211881 Discussion on PRACH Resource for multiple PRACH transmissions FGI
R1-2212562 Discussion on PRACH coverage enhancement Ericsson (rev of R1-2211895)
R1-2211931 Discussion on PRACH repeated transmission for NR coverage enhancement LG Electronics
R1-2212009 Discussion on PRACH coverage enhancements NTT DOCOMO, INC.
R1-2212073 PRACH coverage enhancements Samsung
R1-2212145 PRACH Coverage Enhancements Qualcomm Incorporated
R1-2212181 Views on multiple PRACH transmission for coverage enhancement Sharp
R1-2212255 Discussion on PRACH coverage enhancements MediaTek Inc.
R1-2212273 Discussion on issues of PRACH coverage enhancement Mavenir
R1-2212360 Discussion on PRACH coverage enhancement NEC
R1-2212566 FL Summary#1 on PRACH coverage enhancements Moderator (China Telecom)
From Nov 14th session
Agreement
For multiple PRACH transmissions with same Tx beam, support to differentiate at least between multiple PRACH transmissions and single PRACH transmissions.
Agreement
For multiple PRACH transmissions with same Tx beam, to differentiate the multiple PRACH transmissions with single PRACH transmission, consider one or multiple of the following options.
· Option 1: Multiple PRACH are transmitted with separate preamble on shared ROs.
· Option 2: Multiple PRACH are transmitted on separate ROs.
· Option 3: Partial of multiple PRACHs are transmitted with separate preamble on shared ROs, while the other multiple PRACHs are transmitted on separate ROs.
· Other options are not precluded.
· Note: Shared or separate RO/preamble means that the RO/preamble is shared or separated with single PRACH transmission.
Agreement
Study at least the following case for multiple PRACH transmissions with different Tx beams.
· UE uses different TX beams to transmit the multiple PRACH over ROs associated with the same SSB/CSI-RS
· FFS: UE uses different TX beams to transmit the multiple PRACH over ROs associated with different SSBs /CSI-RSs, where the different SSBs/CSI-RSs are not associated with the same RO.
· Note: not related to decision on CFRA
Note: UE uses different TX beams to transmit the multiple PRACH over ROs associated with different SSBs/CSI-RSs, where the different SSBs/CSI-RSs are associated with the same RO is not considered.
Working Assumption
Simulation results for multiple PRACH transmissions with different beam(s) and same beam(s) (baseline) to be discussed in the next meeting.
· Simulation assumptions in TR 38.830 are used as the starting point for the simulation.
o Focus on FR2.
§ UE antenna configuration 2-2-2(baseline), 1-4-1(optional)
o Performance metric: 0.1% false alarm, 1% miss-detection
o Companies report the number of beams, the beam widths, beam correspondence assumption, and the boresights.
· Channel model for link-level simulation: CDL-A defined in table 7.7.1-1 in TR 38.901.
· Both that UE fulfills beamCorrespondence requirements Without UL-BeamSweeping and UE fulfils beamCorrespondence requirements With UL-BeamSweeping can be considered in the simulation are used as starting point for simulation.
R1-2212567 FL Summary#2 on PRACH coverage enhancements Moderator (China Telecom)
From Nov 17th session
Agreement
For multiple PRACH transmissions with same Tx beam, down-select one option from the following options.
Agreement
Final summary in R1-2212568.
R1-2210880 Discussion on coverage enhancement in power domain Huawei, HiSilicon
R1-2211034 Discussions on issues of power domain enhancements vivo
R1-2211048 Discussion on power domain enhancements ZTE
R1-2211088 Discussion on Power domain enhancements for CA/DC Fujitsu
R1-2211186 Discussion on enhancements to reduce MPR/PAR CATT
R1-2211255 Discussion on power domain enhancements Spreadtrum Communications
R1-2211351 Discussion on power domain enhancements xiaomi
R1-2211424 Discussions on power domain enhancement Intel Corporation
R1-2211475 The study of power domain enhancements OPPO
R1-2211574 Power domain enhancements Lenovo
R1-2211593 Discussion on power domain enhancements Panasonic
R1-2211596 RAN1 impacts for power domain enhancements Nokia, Nokia Shanghai Bell
R1-2211706 Discussion on power domain enhancements CMCC
R1-2211712 Discussion on power domain enhancements InterDigital, Inc.
R1-2211838 Discussion on power domain coverage enhancement Apple
R1-2211896 Power Domain Enhancement Evaluation Methodology and Schemes Ericsson
R1-2212010 Discussion on power domain enhancements NTT DOCOMO, INC.
R1-2212074 Power domain enhancements Samsung
R1-2212146 Power-domain enhancements Qualcomm Incorporated
R1-2212182 Power domain enhancements for Rel-18 CovEnh Sharp
R1-2212256 Discussion on power domain enhancements MediaTek Inc.
R1-2212282 DMRS design for power domain enhancements Indian Institute of Tech (H)
R1-2212573 FL summary of power domain enhancements (AI 9.14.2) Moderator (Nokia)
R1-2212574 FL summary #2 of power domain enhancements (AI 9.14.2) Moderator (Nokia)
From Nov 15th session
Agreement
Agreement
For RAN1 link-level performance
evaluation of MPR/PAR reduction solutions involving the use of Tx spectrum shaping filter, companies are encouraged to use at least the
following spectrum shaping filter configuration for calibration purpose:
There is no restriction to use
other spectrum shaping filter coefficients in simulations, e.g., [1 0.28].
Note: the above does not have spec impact.
Agreement
The following non-transparent solutions for MPR/PAR reduction are currently under discussion in RAN1.
In addition, transparent schemes, for instance but not limited to frequency domain spectrum shaping w/o spectrum extension or schemes based on clipping and filtering, are also being evaluated to serve as a benchmark to assess the benefits of non-transparent solutions. Companies are allowed to use any transparent transmission scheme of their choice.
Agreement
At least the symmetric spectrum extension option for frequency domain spectrum shaping with spectrum extension (FDSS-SE), are considered for studying MPR/PAR reduction enhancements in Rel-18.
Conclusion
It is RAN1 understanding that:
· Performance comparison based on net gain results combining transmitter and receiver performance is performed by RAN4.
· No final decision would be taken by RAN1 on which MPR/PAR reduction solution, will be specified in Rel-18, if any, since this is RAN4’s responsibility.
o It does not preclude RAN1 specification impact
Agreement
For the study of the PAPR/CM of DMRS when considering tone reservation as candidate enhancement for MPR/PAR reduction in Rel-18, RAN1 to consider at least the case that PRTs are added to the DMRS symbols (in the sideband). The case of PRTs not added to DMRS symbols can be used as a benchmark.
Agreement
The LS out RAN1 aims at drafting before the end of RAN1 #111 should include at least the following three parts:
1. List of candidate non-transparent and an initial list of transparent (if any) schemes considered for study by RAN1
2. Schemes-specific parameterization used by RAN1 for evaluation, e.g., spectrum extension factor and cyclic shift (if applicable), sideband size, filter assumptions (if any), channel model and so on.
3. Further parameterizations used in RAN1 evaluations, e.g., carrier frequency, channel model and so on.
R1-2212575 FL summary #3 of power domain enhancements (AI 9.14.2) Moderator (Nokia)
From Nov 17th session
Agreement
The following baseline parameterization is used for link-level performance evaluation of MPR-PAR reduction solutions in RAN1 for Rel-18.
|
Channel |
PUSCH, 14 symbols |
|
Carrier frequency and scenario |
4GHz (Urban), 28GHz (Urban) 700MHz (Rural), |
|
Channel BW |
100MHz for Urban 20MHz for Rural, |
|
SCS |
30 kHz (4GHz), 120 kHz (28GHz) 15 kHz (700 MHz), |
|
Channel model |
TDL-C 300ns for FR1 Urban (4GHz), TDL-A 30ns for FR2 Urban (28GHz), TDL-D 30ns for Rural |
|
UE speed |
3km/h |
|
Waveform |
According to agreements |
|
Modulation |
According to agreements |
|
Number of Tx antennas |
1, Optional: 2 |
|
Number of Rx antennas |
4 for FR1 Urban, 2 for FR2, 2 or 4 for FR1 Rural, |
|
Number of DMRS symbols |
2 |
|
Number of PUSCH data symbols |
12 |
|
HARQ configuration |
No retransmissions |
|
Frequency hopping |
Disabled |
|
Number of PRBs |
Reported by companies |
|
MCS |
Chosen as a function of the number of PRBs to guarantee same spectral efficiency between MPR/PAR reduction solutions and baseline/benchmarks as per agreements |
|
Extension factor [FDSS-SE] / sideband size [TR] (α) |
[1/8, 1/4, 3/8] is encouraged. |
|
BLER |
10% |
For any parameter that is not listed in the table, companies are encouraged to consider corresponding value from TR 38.830 (or TR 38.868, if the parameter is absent in TR 38.830) and report the parameter with the results.
Notes:
· Other configurations and scenarios can be studied, and corresponding results can be reported.
· RAN1 to inform RAN4 about the content of the table.
· This table can be updated in future meetings, especially if alignment with assumptions and parameterization in RAN4 is needed
Agreement
Study the PAPR/CM[/OBO] of DMRS with FDSS-SE, e.g., the following solutions:
· Option 1 - Based on low PAPR Type 1 DMRS sequence:
o 1-a: A DMRS sequence is generated considering the number of PRBs in the inband + extension. The sequence length depends on the number of PRBs in the inband + extension.
o 1-b A DMRS sequence is generated considering the number of PRBs in the inband (no extension). The sequence length depends on the number of PRBs in the inband. The sequence is then cyclically extended to span the PRBs in the extension.
o 1-c A DMRS sequence is generated considering the number of PRBs in the inband (no extension). The sequence length depends on the number of PRBs in the inband. DMRS extension is applied similar to data to span the PRBs in the extension.
· Option 2 - Based on low PAPR type 2 DMRS sequence
o Variances like those of Option 1 can be referred
· Option 3 – For in-band DMRS lengths 6/12/18/24 symbols, DMRS sequence is obtained by DFT transformation of low PAPR sequence type 1. Then the sequence is extended to span the PRBs in the extension in the same way as data extension.
Note: Other solutions can be studied. Comparison with the three solutions above is encouraged. Sequence with different density between in-band and extension can be studied.
R1-2212576 FL summary #4 of power domain enhancements (AI 9.14.2) Moderator (Nokia)
From Nov 18th session
Working Assumption
· The following set of configurations is for companies’ consideration for the calibration of the link performance of MPR/PAR reduction techniques.
|
|
No spectrum extension |
With spectrum extension |
|||||
|
TBS value |
Tput estimation for DDDSU @4GHz |
#PRBs |
MCS |
#PRBs before extension |
#PRBs after extension |
MCS |
Spectrum extension factor |
|
2408 |
963.2 kbps |
16 |
7 |
14 |
16 |
8 |
1/8 |
|
5376 |
~2.15 Mbps |
32 |
8 |
28 |
32 |
9 |
1/8 |
|
272 |
108.8 kbps |
8 |
0 |
6 |
8 |
1 |
¼ |
|
1032 |
412.8 kbps |
8 |
6 |
6 |
8 |
8 |
¼ |
|
2152 |
~0.9 Mbps |
40 |
2 |
30 |
40 |
3 |
¼ |
|
4992 |
~2.0 Mbps |
40 |
6 |
30 |
40 |
8 |
¼ |
|
552 |
220.8 kbps |
16 |
0 |
10 |
16 |
2 |
3/8 |
|
1736 |
694.6 kbps |
32 |
2 |
20 |
32 |
4 |
3/8 |
|
[432 |
172.8 kbps |
8 |
2 |
6 |
8 |
3 |
¼] |
|
[808 |
323.2 kbps |
24 |
0 |
18 |
24 |
1 |
¼] |
· The values above serve as a common basis, but any other configuration and result reported by companies will be considered for any input related to LLS that RAN1 may provide to RAN4.
· Results of the simulations of MPR/PAR reduction solutions which companies may report in contributions to RAN1 #112 should be reported using the template in R1-2212918.
· Note: At least 10% BLER SNR is reported
R1-2212916 [Draft] LS to RAN4 for further information on RAN1 assumptions for LLS performance evaluation of MPR/PAR reduction solutions Moderator (Nokia)
Decision: The draft LS in R1-2212916 is endorsed in principle. Final LS is approved in R1-2212917.
Final FL summary in R1-2212577.
R1-2212918 Template for reporting results of LLS performance evaluations of MPR/PAR reduction solutions Moderator (Nokia)
R1-2210881 Discussion on dynamic waveform switching for coverage enhancement Huawei, HiSilicon
R1-2211035 Discussions on issues of dynamic waveform switching vivo
R1-2211049 Discussion on dynamic waveform switching ZTE
R1-2211089 Discussion on Dynamic switching between DFT-s-OFDM and CP-OFDM Fujitsu
R1-2211134 Discussion on dynamic waveform switching Panasonic
R1-2211187 Dynamic switching between DFT-S-OFDM and CP-OFDM CATT
R1-2211256 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Spreadtrum Communications
R1-2211324 Dynamic switching between DFT-S-OFDM and CP-OFDM InterDigital, Inc.
R1-2211352 Discussion on dynamic switching between DFT-s-OFDM and CP-OFDM xiaomi
R1-2211390 Dynamic switching between DFT-S-OFDM and CP-OFDM waveform Intel Corporation
R1-2211476 Considerations on dynamic switching between DFT-S-OFDM and CP-OFDM OPPO
R1-2211538 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM China Telecom
R1-2211569 Dynamic switching between DFT-S-OFDM and CP-OFDM ETRI
R1-2211575 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Lenovo
R1-2211597 Dynamic switching between DFT-s-OFDM and CP-OFDM Nokia, Nokia Shanghai Bell
R1-2211631 Further considerations on dynamic waveform switching for NR UL Sony
R1-2211707 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM CMCC
R1-2211839 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Apple
R1-2211879 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM FGI
R1-2211897 Discussion on Dynamic UL Waveform Switching Ericsson
R1-2211932 Discussion on dynamic waveform switching for NR coverage enhancement LG Electronics
R1-2212011 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM NTT DOCOMO, INC.
R1-2212075 Dynamic switching between DFT-S-OFDM and CP-OFDM Samsung
R1-2212147 Dynamic switching between DFT-S-OFDM and CP-OFDM Qualcomm Incorporated
R1-2212183 Dynamic switching between DFT-S-OFDM and CP-OFDM for Rel-18 CovEnh Sharp
R1-2212257 Dynamic switching between waveforms MediaTek Inc.
R1-2212272 Discussion on Dynamic switching mechanism of CP-OFDM and DFT-S-OFDM Mavenir
R1-2212361 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM NEC
R1-2212431 Discussion on Dynamic switching between DFT-S-OFDM and CP-OFDM CEWiT
R1-2212445 Summary #1 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
R1-2212446 Summary #2 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
R1-2212445 Summary #1 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From Nov 15th session
Working Assumption
Support at least one of the following options for the dynamic waveform indication in R18:
· Alt 1: Indication from an UL scheduling DCI
o Alt 1-A: New field in scheduling DCI
o Alt 1-B: Reuse existing field in scheduling DCI
§ Alt 1-B-1: Explicit indication by repurposing field, e.g.
· Add one column to TDRA table
· Add one column to MCS table(s)
· Other solutions not precluded
§ Alt 1-B-2: Implicit determination from condition(s) on scheduling information, e.g.
· RA type, MSB of RA
· Number of RBs (below threshold or multiple of 2,3,5)
· Location of RB allocation within carrier and the associated MPR
· MCS below threshold
· Number of PUSCH repetitions (or whether PUSCH repetition is used) and/or TBoMS
· Number of DMRS CDM group(s) without data
· Precoding information and number of layers
· SRI
· Condition over multiple types of scheduling information
· Other types of scheduling information not precluded
o Indicated waveform applies at least to the scheduled PUSCH transmission
o FFS: Whether it also applies to subsequent transmissions, and of which type
o FFS: DCI formats can contain the indication
o FFS: Indication applies only if condition(s) are satisfied (e.g. PDCCH occasion, /RNTI, /Search space of the scheduling DCI, latest PHR reported by the UE, etc.)
· Alt 2: Indication from a non-UL scheduling DCI
o FFS: DCI formats that can provide the indication (e.g. Downlink DCI, UE-group common DCI)
o FFS: Types of subsequent transmissions to which indication is applicable
Agreement
For DCI based solution,
· For supported dynamically scheduled PUSCH, support dynamic waveform switching indication from UL scheduling DCI
o Note: “Supported dynamically scheduled PUSCH” is to be confirmed in further discussion
o Note: It does not imply that the waveform switching indication applies to other transmission or not
Note: the working assumption made in RAN1#110b-e for “Support at least one of the following options for the dynamic waveform indication in R18” does not need to be confirmed
R1-2212446 Summary #2 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From Nov 17th session
Working Assumption
Support new 1-bit field for dynamic waveform indication from UL scheduling DCI
· Note: no change of the current size alignment procedure between UL DCI and DL DCI
Agreement
Study the necessity of the following potential enhancements to assist the scheduler in determining waveform switching:
· Reporting power headroom related information based on PCMAX,f,c applicable to a target waveform
o Target waveform can be same or different from waveform of an actual PUSCH transmission
o FFS target RB allocation and/or target modulation order can be same or different from respective properties of an actual PUSCH transmission
o FFS determination of target waveform, target RB allocation, target modulation order
o FFS details, e.g. report PCMAX,f,c or Type 1 power headroom for a waveform, or difference thereof between waveforms
· PHR triggering enhancements, e.g.
o Network-triggered PHR
o PH becomes lower (higher) than a threshold
o PHR triggered by waveform switching
· Reporting of recommended waveform or request to switch waveform
· Other solutions not precluded
Final summary in R1-2212983.
Please refer to RP-221858 for detailed scope of the WI on further NR coverage enhancements.
R1-2302069 Session notes for 9.14 (Further NR coverage enhancements) Ad-Hoc Chair (CMCC)
[112-R18-CovEnh] – Nanxi (China Telecom)
To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2300089 Discussion on PRACH coverage enhancements Huawei, HiSilicon
R1-2300244 Discussion on PRACH coverage enhancements Spreadtrum Communications
R1-2300276 PRACH coverage enhancements OPPO
R1-2300344 Discussion on PRACH coverage enhancements ZTE
R1-2300479 Discussions on PRACH coverage enhancements vivo
R1-2300495 Discussion on Resource Allocation for Multiple PRACH Transmission FGI
R1-2301770 Discussion on PRACH coverage enhancements xiaomi (rev of R1-2300561)
R1-2300667 PRACH coverage enhancements CATT
R1-2300728 Discussion on PRACH coverage enhancement China Telecom
R1-2300758 Discussion on PRACH coverage enhancements Fujitsu
R1-2300796 Discussion on PRACH coverage enhancements Panasonic
R1-2300828 Discussion on PRACH coverage enhancement NEC
R1-2300838 PRACH coverage enhancements TCL Communication Ltd.
R1-2300860 PRACH coverage enhancements Lenovo
R1-2300894 PRACH Coverage Enhancement using Multi PRACH Transmissions Sony
R1-2300904 Discussion on PRACH coverage enhancement Mavenir
R1-2300972 Discussions on PRACH coverage enhancement Intel Corporation
R1-2301027 Discussion on PRACH coverage enhancements CMCC
R1-2301053 PRACH coverage enhancements ETRI
R1-2301074 Discussion on PRACH repeated transmission for NR coverage enhancement LG Electronics
R1-2301171 Discussion on PRACH coverage enhancements InterDigital Communications
R1-2301185 Discussion on PRACH coverage enhancement Ericsson
R1-2301292 PRACH coverage enhancements Samsung
R1-2301374 Discussion on PRACH coverage enhancement Apple
R1-2301441 PRACH Coverage Enhancements Qualcomm Incorporated
R1-2301519 Discussion on PRACH coverage enhancements NTT DOCOMO, INC.
R1-2301550 Views on multiple PRACH transmission for coverage enhancement Sharp
R1-2301777 On PRACH coverage enhancements MediaTek Inc. (rev of R1-2301603)
R1-2301654 PRACH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2301848 FL Summary#1 on PRACH coverage enhancements Moderator (China Telecom)
From Monday session
Agreement
For multiple PRACH transmissions with same Tx beam, gNB can configure one or multiple values for the number of multiple PRACH transmissions.
Working Assumption
For multiple PRACH transmissions with same Tx beam, to differentiate the multiple PRACH transmissions with single PRACH transmission, at least support that multiple PRACH are transmitted on separate ROs.
Working Assumption
For multiple PRACH transmissions with same Tx beam, to differentiate the multiple PRACH transmissions with single PRACH transmission, support that multiple PRACH are transmitted with separate preamble on shared ROs.
R1-2301849 FL Summary#2 on PRACH coverage enhancements Moderator (China Telecom)
From Wednesday session
Conclusion
For multiple PRACH transmissions within one RACH attempt, they are only transmitted over ROs associated with the same SSB/CSI-RS.
Note: This applies for multiple PRACH transmissions with same Tx beam, and also applies for multiple PRACH transmissions with different Tx beam (if supported).
Agreement
For multiple PRACH transmissions with same Tx beam in one RACH attempt, transmission power ramping is not applied within one RACH attempt.
Agreement
For multiple PRACH transmissions with same Tx beam, only one RAR window is supported for RAR monitoring for one RACH attempt.
· FFS: the start position of the RAR window.
· FFS: RA-RNTI.
Agreement
For multiple PRACH transmissions with same Tx beam, "RO group" is assumed for multiple PRACH transmissions with separate preamble on shared ROs and/or multiple PRACH transmissions on separate ROs, and one RO group consists of valid RO(s) for a specific number of multiple PRACH transmissions.
· Note 1: All ROs in one RO group is associated with the same SSB(s).
· Note 2: Shared or separate RO/preamble means that the RO/preamble is shared or separated with single PRACH transmission.
· Note 3: whether/how to define “RO group” in specification will be discussed separately
· Note 4: Valid RO(s) refers to what is defined in existing specification
· FFS: whether and how to address collision between valid ROs for multiple PRACH transmissions and other existing ROs for legacy single PRACH transmission or other features, e.g., 2-step RACH.
· FFS: the time span of RO group.
· FFS: whether and how ROs can be shared between different RO groups for different number of multiple PRACH transmissions.
· FFS: other details
R1-2301850 FL Summary#3 on PRACH coverage enhancements Moderator (China Telecom)
From Thursday session
Agreement
Support {2, 4, 8} for the number of multiple PRACH transmissions with same Tx beams.
Note: It is summarized by FL that for the same number of PRACH transmissions per source,
· 1 source [Ericsson] shows that: Multiple PRACH transmitted by beam sweeping, where a UE has no prior knowledge of channel and sweeps Tx beams across 360 degrees horizontally and 180 degrees vertically, outperforms multiple PRACH transmissions with the same Tx wide beam (omni direction) by at least 1 dB, provided gNB configures only one SSB and receives PRACH with a wide beam.
· 3 sources [ZTE, Nokia, vivo] show that: A gain from about 1~3 dB of beam sweeping is observed if a UE is able to direct at least one of its Tx beams in the right direction or to narrow down the azimuth and/or zenith range of 360 degrees and/or 180 degrees for beam sweeping compared with multiple PRACH transmissions with the same Tx wide beam.
· 1 source [Huawei] shows that: compared to the same wide beam for multiple PRACH transmission, if different Tx beams are finer beams, then 3.9~5 dB gains are observed assuming that only one PRACH occasion with the best detected SINR is selected at the gNB reception, where the beam gain of fine beam is 4 times that of wide beam.
· 1 source [vivo] shows that: The performance of PRACH repetition with beam sweeping among beams far apart is 3 dB worse than PRACH repetition with single best beam
· 1 source [vivo] shows that: The performance of PRACH repetition with beam sweeping among beams in the directions close to the best Tx beam is 1dB worse than PRACH repetition with single best beam.
· 1 source [vivo] shows that: PRACH repetition via random beam directions performs 1 dB worse than PRACH repetition with omni beam.
R1-2300090 Discussion on coverage enhancement in power domain Huawei, HiSilicon
R1-2300245 Discussion on power domain enhancements Spreadtrum Communications
R1-2300277 The study of power domain enhancements OPPO
R1-2300345 Discussion on power domain enhancements ZTE
R1-2300480 Discussions on power domain enhancements vivo
R1-2300562 Discussion on power domain enhancements xiaomi
R1-2300668 Discussion on MPR/PAR reduction enhancements CATT
R1-2300729 Discussion on power domain enhancements China Telecom
R1-2300759 Discussion on Power domain enhancements Fujitsu
R1-2300797 Discussion on power domain enhancements Panasonic
R1-2300861 Power domain enhancements Lenovo
R1-2300895 Considerations on tone reservation for PAPR reduction Sony
R1-2300973 Discussions on power domain enhancement Intel Corporation
R1-2301028 Discussion on power domain enhancements CMCC
R1-2301172 Discussion on power domain enhancements InterDigital Communications
R1-2301186 Power Domain Enhancement Schemes and Performance Ericsson
R1-2301293 Power domain enhancements Samsung
R1-2301375 Discussion on power domain coverage enhancement Apple
R1-2301442 Power-domain enhancements Qualcomm Incorporated
R1-2301520 Discussion on power domain enhancements NTT DOCOMO, INC.
R1-2301778 Views on power domain enhancements MediaTek Inc. (rev of R1-2301604)
R1-2301995 DMRS design for power domain enhancements Indian Institute of Tech (H) (rev of R1-2301635)
R1-2301655 RAN1 impacts for power domain enhancements Nokia, Nokia Shanghai Bell
R1-2301869 FL summary of power domain enhancements (AI 9.14.2) Moderator(Nokia)
R1-2301870 FL summary #2 of power domain enhancements (AI 9.14.2) Moderator (Nokia)
R1-2301871 FL summary #3 of power domain enhancements (AI 9.14.2) Moderator (Nokia)
From Wednesday session
Agreement
Further discussions in RAN1 concerning means to facilitate higher power transmissions in CA and DC, if applicable, can target increasing gNB awareness of UE’s Tx power, e.g., PHR reporting enhancement such as current power class, power class change, or application of P-MPR by UE (subject to RAN4’s input).
o FFS: details.
Agreement
If FDSS-SE is supported in Rel-18, RAN1 to further study the following approaches for DMRS, when the DMRS sequence length before extension of the sequence, if any, is larger than or equal to 30:
· Approach A – the DMRS sequence is extended: A DMRS sequence is generated considering the number of PRBs in the inband (no extension). The sequence length depends on the number of PRBs in the inband. Two sequence types can be considered:
FFS: how the sequence is extended.
Note:
if low PAPR type 2 is used then both the number of PRBs in the inband
and the number of PRBs in the inband+extension must be valid DFT sizes as per
NR specification
Performance metrics considered for the study are PAPR, CM[, and OBO] for DMRS and 10% BLER SNR for data (to measure channel estimation accuracy).
Agreement
If FDSS-SE is supported in Rel-18, and RB allocations resulting in DMRS sequence length smaller than 30 before extension of the sequence, if any, are supported, RAN1 to study at least the following approaches:
FFS: how the sequence is extended.
Note:
if low PAPR type 2 is used then both the number of PRBs in the inband
and the number of PRBs in the inband+extension must be valid DFT sizes as per
NR specification
Note: Other sequences are not precluded for Approach A and Approach B.
Performance metrics considered for the study are PAPR, CM [, and OBO] for DMRS and 10% BLER SNR for data (to measure channel estimation accuracy).
Agreement
Include in the LS to RAN4 for reporting LLS results
Note: The excel file is used to collect the results.
R1-2301872 FL summary #4 of power domain enhancements (AI 9.14.2) Moderator (Nokia)
From Thursday session
Working Assumption
· The following set of configurations is for companies’ consideration for the comparsion of the performance of DMRS with FDSS-SE.
|
No spectrum extension |
With spectrum extension |
||||
|
#PRBs |
MCS |
#PRBs before extension |
#PRBs after extension |
MCS |
Spectrum extension factor |
|
8 |
0 [only QPSK] |
6 |
8 |
1 [only QPSK] |
¼ |
|
8 |
6 |
6 |
8 |
8 |
¼ |
|
40 |
2 |
30 |
40 |
3 |
¼ |
|
40 |
6 |
30 |
40 |
8 |
¼ |
|
|
|
|
|
|
|
|
[6 |
3 |
4 |
6 |
5 |
1/3] |
|
[36 |
7 |
32 |
36 |
8 |
1/9] |
· FR1 4GHz Urban scenario is prioritized.
· The following filters are for companies’ consideration for the calibration of the performance of DMRS with FDSS-SE
o 3-tap (0.28 1 0.28)
o [Truncated RRC (0.5, 0.1667) or 2-tap (1 0.28)]
· Note1: Considered metrics are PAPR/CM, 10% BLER SNR of data for the considered DMRS configuration (for measuring impact of channel estimation accuracy)[, and OBO]
· Note2: companies are encouraged to consider a receiver which at least makes use of the extension for the decoding (e.g., MRC)
· Note3: The values above serve as a common basis, but any other configuration can be studied by companies.
R1-2302080 [Draft] LS to RAN4 for results of the LLS performance evaluation of MPR/PAR reduction solutions Moderator (Nokia)
Decision: The Draft LS R1-2302080 is endorsed in principle. Final LS is approved in R1-2302081.
Final summary in R1-2301873.
R1-2300091 Discussion on dynamic waveform switching for coverage enhancement Huawei, HiSilicon
R1-2300246 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Spreadtrum Communications
R1-2300278 Considerations on dynamic switching between DFT-S-OFDM and CP-OFDM OPPO
R1-2300346 Discussion on dynamic waveform switching ZTE
R1-2300481 Discussions on dynamic waveform switching vivo
R1-2300563 Discussion on dynamic switching between DFT-s-OFDM and CP-OFDM xiaomi
R1-2300669 Dynamic switching between DFT-S-OFDM and CP-OFDM CATT
R1-2300730 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM China Telecom
R1-2300829 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM NEC
R1-2300856 Dynamic switching between DFT-S-OFDM and CP-OFDM InterDigital, Inc.
R1-2300862 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Lenovo
R1-2300864 Discussion on dynamic waveform switching Panasonic
R1-2300896 Further considerations on dynamic waveform switching for the UE UL Sony
R1-2300903 Discussion on solutions for NR dynamic switching between DFT-S-OFDM and CP-OFDM Mavenir
R1-2300974 Dynamic switching between DFT-S-OFDM and CP-OFDM waveform Intel Corporation
R1-2301029 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM CMCC
R1-2301054 Dynamic switching between DFT-S-OFDM and CP-OFDM ETRI
R1-2301075 Discussion on dynamic waveform switching for NR coverage enhancement LG Electronics
R1-2301086 Discussion on dynamic waveform switching DENSO CORPORATION
R1-2301187 Discussion on Dynamic UL Waveform Switching Ericsson
R1-2301294 Dynamic switching between DFT-S-OFDM and CP-OFDM Samsung
R1-2301312 Discussion of dynamic switching between DFT-S-OFDM and CP-OFDM Transsion Holdings
R1-2301376 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Apple
R1-2301443 Dynamic switching between DFT-S-OFDM and CP-OFDM Qualcomm Incorporated
R1-2301521 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM NTT DOCOMO, INC.
R1-2301540 Summary #1 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
R1-2301541 Summary #2 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
R1-2301551 Dynamic switching between DFT-S-OFDM and CP-OFDM for Rel-18 CovEnh Sharp
R1-2301779 Dynamic switching between waveforms MediaTek Inc. (rev of R1-2301605)
R1-2301656 Dynamic switching between DFT-s-OFDM and CP-OFDM Nokia, Nokia Shanghai Bell
R1-2301540 Summary #1 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
R1-2301541 Summary #2 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From Wednesday session
Agreement
For single TB scheduled by single DCI, support new 1-bit field for dynamic waveform indication from UL scheduling DCI.
Note: no change of the current size alignment procedure between UL DCI and DL DCI.
R1-2302124 Summary #3 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From Thursday session
Conclusion
There is no consensus to support “Dynamic waveform switching to PUSCH transmissions with a Type 2 configured grant” in R18.
Agreement
Dynamic waveform switching in R18 is not applicable to PUSCH transmissions with a Type 1 configured grant.
Conclusion
The dynamic waveform indication in a DCI containing a dynamic uplink grant applies only to PUSCH transmission(s) corresponding to the dynamic uplink grant.
Final summary in R1-2302222.
Please refer to RP-221858 for detailed scope of the WI on further NR coverage enhancements.
R1-2304174 Session notes for 9.12 (Further NR coverage enhancements) Ad-Hoc Chair (CMCC)
R1-2302350 Discussion on PRACH coverage enhancements Huawei, HiSilicon
R1-2302509 Discussions on remaining issues of PRACH coverage enhancements vivo
R1-2302573 PRACH coverage enhancements OPPO
R1-2302623 Discussion on PRACH coverage enhancements Spreadtrum Communications
R1-2302690 PRACH coverage enhancements CATT
R1-2302759 Discussion on PRACH coverage enhancements ZTE
R1-2302818 Discussions on PRACH coverage enhancement Intel Corporation
R1-2302835 PRACH coverage enhancements TCL Communication Ltd.
R1-2302863 PRACH Coverage Enhancement using Multiple PRACH Transmissions Sony
R1-2302880 PRACH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2302885 Discussion on PRACH coverage enhancements Panasonic
R1-2302915 Discussion on PRACH coverage enhancements Fujitsu
R1-2302970 Discussion on PRACH coverage enhancements xiaomi
R1-2303034 Discussion on PRACH coverage enhancement China Telecom
R1-2303086 Discussion on solutions for NR PRACH coverage enhancement Mavenir
R1-2303090 PRACH coverage enhancements Lenovo
R1-2303153 PRACH coverage enhancements Samsung
R1-2303206 PRACH coverage enhancements ETRI
R1-2303209 Discussion on PRACH coverage enhancements Quectel
R1-2303256 Discussion on PRACH coverage enhancements CMCC
R1-2303353 On PRACH coverage enhancements MediaTek Inc.
R1-2303411 Discussion on CFRA for Multiple PRACH Transmission FGI
R1-2303453 Discussion on PRACH coverage enhancements InterDigital, Inc.
R1-2303508 Discussion on PRACH coverage enhancement Apple
R1-2303615 PRACH Coverage Enhancements Qualcomm Incorporated
R1-2303640 Views on multiple PRACH transmission for coverage enhancement Sharp
R1-2303661 Discussion on PRACH coverage enhancement Ericsson
R1-2303681 Discussion on PRACH coverage enhancement NEC
R1-2303731 Discussion on PRACH coverage enhancements NTT DOCOMO, INC.
R1-2303750 Discussion on PRACH repeated transmission for NR coverage enhancement LG Electronics
[112bis-e-R18-Coverage-01] – Nanxi (China Telecom)
Email discussion on PRACH coverage enhancement by April 26th
- Check points: April 21, April 26
R1-2303959 FL Summary#1 on PRACH coverage enhancements Moderator (China Telecom)
From April 17th GTW session
Agreement
Confirm the following working assumptions.
|
Working Assumption For multiple PRACH transmissions with same Tx beam, to differentiate the multiple PRACH transmissions with single PRACH transmission, at least support that multiple PRACH are transmitted on separate ROs. · Note: Separate RO means that the RO is separated with single PRACH transmission. · FFS: whether Rel-17 framework of feature combination (FeatureCombination-r17) and additional RACH configuration (AdditionalRACH-Config-r17) can be reused for Rel-18 multiple PRACH transmissions to realize the corresponding PRACH resource partitioning.
Working Assumption For multiple PRACH transmissions with same Tx beam, to differentiate the multiple PRACH transmissions with single PRACH transmission, support that multiple PRACH are transmitted with separate preamble on shared ROs. · Note: Shared or separate RO/preamble means that the RO/preamble is shared or separated with single PRACH transmission. · FFS: whether Rel-17 framework of feature combination (FeatureCombination-r17) and additional RACH configuration (AdditionalRACH-Config-r17) can be reused for Rel-18 multiple PRACH transmissions to realize the corresponding PRACH resource partitioning. |
R1-2303960 FL Summary#2 on PRACH coverage enhancements Moderator (China Telecom)
From April 19th GTW session
Agreement
Send LS to inform RAN2 about the 2 confirmed Working Assumptions, and details on how to realize PRACH resource partitioning is up to RAN2.
Conclusion
There is no consensus to support multiple PRACH transmissions within one RACH attempt located at same time instance in Rel-18.
Note: multiple PRACH transmissions within one RACH attempt located at same time instance includes multiple PRACH transmissions in FDMed ROs located at the same time instance and multiple PRACH transmissions with different preambles in the same RO.
R1-2303961 FL Summary#3 on PRACH coverage enhancements Moderator (China Telecom)
From April 21st GTW session
Conclusion
There is no consensus to support utilizing different preambles during the multiple PRACH transmissions with the same Tx beam in one attempt.
Agreement
· Multiple PRACH transmissions within one RACH attempt are only performed within one RO group.
o The number of valid ROs in the RO group is equal to one of the configured number(s) of multiple PRACH transmissions.
§ Note1: If only one value is configured for multiple PRACH transmissions, then the number of valid ROs in the RO group is equal to this value.
§ Note2: If multiple values are configured for multiple PRACH transmissions, for each value, the number of valid ROs in the RO group is equal to the corresponding number of multiple PRACH transmissions.
§ Note 3: Valid RO(s) refers to what is defined in existing specification.
R1-2304070 [Draft] LS on PRACH coverage enhancement China Telecom
Decision: [Draft] LS R1-2304070 is endorsed in principle by appending RAN1 agreement “Agreement
Send LS to inform RAN2 about the 2 confirmed Working Assumptions, and details on how to realize PRACH resource partitioning is up to RAN2”, as well as fixing the formulation of the LS.
Agreement
Final LS R1-2304141 is approved.
R1-2303962 FL Summary#4 on PRACH coverage enhancements Moderator (China Telecom)
From April 25th GTW session
Agreement
The starting point of RAR window is after the last symbol of the last valid RO in the RO group corresponding to the multiple PRACH transmissions.
Note: Valid RO(s) refers to what is defined in existing specification, i.e., Section 8.1 in TS 38.213.
Note: The last valid RO is irrespective of whether the PRACH transmission on the last valid RO in the RO group is dropped or not.
R1-2304234 Final summary on PRACH coverage enhancements Moderator (China Telecom)
R1-2302351 Discussion on coverage enhancement in power domain Huawei, HiSilicon
R1-2302510 Discussions on remaining issues of power domain enhancements vivo
R1-2302574 The study of power domain enhancements OPPO
R1-2302624 Discussion on power domain enhancements Spreadtrum Communications
R1-2302691 Discussion on MPR/PAR reduction enhancements CATT
R1-2302760 Discussion on power domain enhancements ZTE
R1-2302787 Discussions on power domain enhancement Intel Corporation
R1-2302864 Considerations on tone reservation for PAPR reduction Sony
R1-2302881 RAN1 impacts for power domain enhancements Nokia, Nokia Shanghai Bell
R1-2302886 Discussion on power domain enhancements Panasonic
R1-2302916 Discussion on Power domain enhancements Fujitsu
R1-2302971 Discussion on power domain enhancements Xiaomi
R1-2303035 Discussion on power domain enhancements China Telecom
R1-2303091 Power domain enhancements Lenovo
R1-2303154 Power domain enhancements Samsung
R1-2303257 Discussion on power domain enhancements CMCC
R1-2303354 Views on power domain enhancements MediaTek Inc.
R1-2303454 Discussion on power domain enhancements InterDigital, Inc.
R1-2303509 Discussion on power domain coverage enhancement Apple
R1-2303616 Power-domain enhancements Qualcomm Incorporated
R1-2303658 Discussion on power domain enhancements Google Inc.
R1-2303662 Power Domain Enhancement Schemes and Performance Ericsson
R1-2303732 Discussion on power domain enhancements NTT DOCOMO, INC.
R1-2303751 Discussion on Power Domain Enhancements LG Electronics
R1-2303767 Power domain enhancements for Rel-18 CovEnh Sharp
R1-2303777 DMRS design for power domain enhancements Indian Institute of Tech (H)
[112bis-e-R18-Coverage-02] – Marco (Nokia)
Email discussion on power domain enhancements by April 26th
- Check points: April 21, April 26
R1-2303921 FL summary of power domain enhancements (AI 9.12.2) Moderator (Nokia)
Presented in April 17th GTW session
R1-2303922 FL summary #2 of power domain enhancements (AI 9.12.2) Moderator (Nokia)
Presented in April 19th GTW session
R1-2303923 FL summary #3 of power domain enhancements (AI 9.12.2) Moderator (Nokia)
From April 21st GTW session
Agreement
· If FDSS-SE is supported in Rel-18, DMRS are mapped on PRBs of both inband and extension and gNB can assume that they are filtered using the same Tx shaping filter as data.
· FFS: whether and which optimizations to Rel-15 and/or Rel-16 DMRS, including sequence extension and/or mapping, to be used with FDSS-SE, are needed.
· Note: whether this will have RAN1 specification impact (if any) is a separate discussion and subject to RAN4’s conclusion to support FDSS-SE as one MPR/PAR reduction solution for Rel-18 (if any).
R1-2303924 FL summary #4 of power domain enhancements (AI 9.12.2) Moderator (Nokia)
From April 25th GTW session
Observation
RAN1 discussed advantages and disadvantages of solutions included in R1-2302270 (R4-2303701) on enhancements to realize increasing UE power high limit for CA and DC. Pros and cons of the inclusion in the PHR report of at least one of the following quantities have been analyzed for different reporting mechanisms, triggers, and reporting periodicities:
· ∆PPowerClass
· Power class
· P-MPR
· Start and length of evaluation period for power class fallback
· Estimated duration of power class fallback
· Estimated duration over which UE can sustain Pcmax before additional P-MPR is required
· Sustainable duty cycle to prevent a fallback
· Energy/power availability
Note: Discussion is still ongoing, and its full current content can be found in Section 2.1.2 of R1-2303924.
R1-2303925 Final FL summary of power domain enhancements (AI 9.12.2) Moderator (Nokia)
R1-2302352 Discussion on dynamic waveform switching for coverage enhancement Huawei, HiSilicon
R1-2302511 Discussions on remaining issues of dynamic waveform switching vivo
R1-2302575 Considerations on dynamic switching between DFT-S-OFDM and CP-OFDM OPPO
R1-2302625 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Spreadtrum Communications
R1-2302692 Dynamic switching between DFT-S-OFDM and CP-OFDM CATT
R1-2302761 Discussion on dynamic waveform switching ZTE
R1-2302788 Dynamic switching between DFT-S-OFDM and CP-OFDM waveform Intel Corporation
R1-2302865 Considerations on dynamic waveform switching for various PUSCH types Sony
R1-2302882 Dynamic switching between DFT-s-OFDM and CP-OFDM Nokia, Nokia Shanghai Bell
R1-2302972 Discussion on dynamic switching between DFT-s-OFDM and CP-OFDM Xiaomi
R1-2303018 Dynamic switching between DFT-S-OFDM and CP-OFDM InterDigital, Inc.
R1-2303036 Discussion on dynamic waveform switching between DFT-s-OFDM and CP-OFDM China Telecom
R1-2303039 Discussion on dynamic waveform switching Panasonic
R1-2303085 Discussion on solutions for NR dynamic switching between DFT-S-OFDM and CP-OFDM Mavenir
R1-2303092 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Lenovo
R1-2303155 Dynamic switching between DFT-S-OFDM and CP-OFDM Samsung
R1-2303207 Dynamic switching between DFT-S-OFDM and CP-OFDM ETRI
R1-2303258 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM CMCC
R1-2303355 Dynamic switching between waveforms MediaTek Inc.
R1-2303382 Discussion of dynamic switching between DFT-S-OFDM and CP-OFDM Transsion Holdings
R1-2303510 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Apple
R1-2303617 Dynamic switching between DFT-S-OFDM and CP-OFDM Qualcomm Incorporated
R1-2303641 Dynamic switching between DFT-S-OFDM and CP-OFDM for Rel-18 CovEnh Sharp
R1-2303644 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Google Inc.
R1-2303663 Discussion on Dynamic UL Waveform Switching Ericsson
R1-2303682 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM NEC
R1-2303733 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM NTT DOCOMO, INC.
R1-2303752 Discussion on dynamic waveform switching for NR coverage enhancement LG Electronics
[112bis-e-R18-Coverage-03] – Paul (InterDigital)
Email discussion on dynamic switching between DFT-S-OFDM and CP-OFDM by April 26
- Check points: April 21, April 26
R1-2303788 Summary #1 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From April 17th GTW session
Agreement
For DCI format 0_1/0_2 containing dynamic waveform indication, bit width of each field is set to the maximum between the bit width of the field if transform precoding is disabled and the bit width of the field if transform precoding is enabled, if different.
· If, for the waveform indicated in the DCI, the bit width N of a field would be smaller than the bit width of the field set as per the above, UE decodes the field using N least significant bits. If N=0, the UE ignores the field for the indicated waveform.
R1-2303789 Summary #2 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From April 19th GTW session
Agreement
For potential enhancements to assist the scheduler in determining waveform switching, RAN1 to select 1 from the following options:
Conclusion
For PUSCH transmission scheduled by C-RNTI with DCI format 0_0, UE considers transform precoding enabled or disabled according to msg3-transformPrecoder as in legacy.
R1-2303790 Summary #3 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From April 21st GTW session
Agreement
Dynamic waveform switching is configured separately for each BWP, within PUSCH-Config.
Agreement
For UE configured with multi-PUSCH scheduling in time domain in a carrier (i.e. pusch-TimeDomainAllocationListForMultiPUSCH), DCI format 0_1 supports 1-bit field for dynamic waveform switching indication.
· When configured, 1-bit field indicates waveform for all scheduled PUSCH transmissions.
Agreement
For PUSCH scheduled by DCI format 0_1/0_2 with dynamic waveform switching indication field configured, and useInterlacePUCCH-PUSCH is not configured, downselect between following options:
· Option 1 (configuration restriction with error case handling):
o UE does not expect resourceAllocation set to resourceAllocationType0.
o If DFT-S-OFDM is indicated and resourceAllocation set to dynamicSwitch, UE does not expect MSB of FDRA field set to 0.
· Option 2 (UE only uses resourceAllocation if CP-OFDM is indicated):
o If DFT-S-OFDM is indicated, UE applies type 1 resource allocation.
o If CP-OFDM is indicated, UE applies resource allocation according to resourceAllocation IE.
o Size of FDRA field is aligned between size for type 1 resource allocation and size according to resourceAllocation IE.
Agreement
For PUSCH scheduled by DCI format 0_1/0_2 with dynamic waveform switching indication field configured, downselect between following options:
· Option 1 (configuration restriction with error case handling):
o UE does not expect dmrs-Type to be set to type2.
· Option 2 (UE only uses dmrs-Type if CP-OFDM is indicated):
o If DFT-S-OFDM is indicated, UE applies DMRS type 1.
o If CP-OFDM is indicated, UE applies DMRS type according to dmrs-Type.
Agreement
For configuration of 1-bit dynamic waveform switching indication in DCI format 0_1/0_2 per a carrier, downselect between following options:
· Option 1: Separate configuration of presence of dynamic waveform switching field for DCI format 0_1 and DCI format 0_2.
· Option 2: Common configuration of presence of dynamic waveform switching field for DCI format 0_1 and DCI format 0_2.
Final summary in R1-2304222.
Please refer to RP-221858 for detailed scope of the WI on further NR coverage enhancements.
R1-2306148 Session notes for 9.12 (Further NR coverage enhancements) Ad-Hoc Chair (CMCC)
[113-R18-CovEnh] – Nanxi (China Telecom)
Email discussion on coverage enhancement
- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2304383 Discussions on PRACH coverage enhancements New H3C Technologies Co., Ltd.
R1-2304503 Discussions on remaining issues of PRACH coverage enhancements vivo
R1-2304580 Discussion on PRACH coverage enhancements Spreadtrum Communications
R1-2304598 Discussion on PRACH coverage enhancements ZTE
R1-2304649 Discussion on PRACH coverage enhancements Huawei, HiSilicon
R1-2304717 PRACH coverage enhancements CATT
R1-2304775 Discussion on PRACH coverage enhancements Fujitsu
R1-2304807 Discussions on PRACH coverage enhancement Intel Corporation
R1-2304865 Discussion on PRACH coverage enhancement China Telecom
R1-2304884 Discussion on PRACH coverage enhancements xiaomi
R1-2304975 PRACH coverage enhancements Lenovo
R1-2304999 Discussion on PRACH coverage enhancement NEC
R1-2305053 PRACH Coverage Enhancement using Multiple PRACH Transmissions Sony
R1-2305115 Discussion on PRACH coverage enhancements CMCC
R1-2305136 PRACH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2305139 PRACH coverage enhancements TCL Communication Ltd.
R1-2305151 Discussion on PRACH coverage enhancements Quectel
R1-2305190 PRACH coverage enhancements Charter Communications, Inc
R1-2305271 Discussion on PRACH coverage enhancement Apple
R1-2305306 Discussion on PRACH coverage enhancements Panasonic
R1-2305361 PRACH Coverage Enhancements Qualcomm Incorporated
R1-2305392 Discussion on PRACH repeated transmission for NR coverage enhancement LG Electronics
R1-2305453 PRACH coverage enhancements OPPO
R1-2306008 Discussion on PRACH coverage enhancement Ericsson (rev of R1-2305483)
R1-2305538 PRACH coverage enhancements Samsung
R1-2305569 Views on multiple PRACH transmission for coverage enhancement Sharp
R1-2305616 Discussion on PRACH coverage enhancements NTT DOCOMO, INC.
R1-2305664 On PRACH coverage enhancements MediaTek Inc.
R1-2305687 Discussion on PRACH coverage enhancement Mavenir
R1-2305802 PRACH coverage enhancements ETRI
R1-2305858 Discussion on PRACH coverage enhancements InterDigital, Inc.
R1-2306036 FL Summary#1 on PRACH coverage enhancements Moderator (China Telecom)
From Monday session
Agreement
A set of RO group(s) for a configured number of multiple PRACH transmissions is determined/configured within a time period X, starting from frame 0. The determined/configured set of RO groups repeats every time period X.
· The time period X is K SSB-to-RO association pattern periods.
· Note: Whether/how to introduce SSB-to-RO group mapping.
· FFS: K is configured by the network or determined based on some rule.
R1-2306037 FL Summary#2 on PRACH coverage enhancements Moderator (China Telecom)
From Tuesday session
Conclusion
If multiple values for the number of multiple PRACH transmissions are configured, support both options to differentiate between multiple PRACH transmissions with different numbers.
· Option 1: Multiple PRACH transmissions with different numbers are transmitted on separate ROs.
· Option 2: Multiple PRACH transmissions with different numbers are transmitted with separate preamble on shared ROs.
Note: Shared or separate RO/preamble means that the RO/preamble is shared or separated between multiple PRACH transmissions with different numbers.
Agreement
If one or more PRACH transmission(s) of the multiple PRACH transmissions in one PRACH attempt are dropped based on the rules causing to drop PRACH transmission(s) in existing spec., the dropped PRACH transmission(s) is not postponed.
· FFS: whether to introduce new rules causing to drop PRACH transmission.
· FFS: whether there is standard impact if the dropped PRACH transmission affect the remaining PRACH transmission within the same RO group.
Agreement
RA-RNTI is calculated based on the last valid RO in the RO group corresponding to the multiple PRACH transmissions.
Note 1: Valid RO(s) refers to what is defined in existing specification, i.e., Section 8.1 in TS 38.213.
Note 2: The last valid RO is irrespective of whether the PRACH transmission on the last valid RO in the RO group is dropped or not.
Conclusion
There is no consensus to support Multiple PRACH transmission with different Tx beams in Rel-18.
Agreement (Made in RAN1#111)
For multiple PRACH transmissions
with same Tx beam, at least SSB-RSRP threshold(s) are used to determine the
number of PRACH transmissions at least for the first RACH attempt.
Note: whether to support multiple numbers of PRACH transmissions is separately discussed.
Agreement (Made in RAN1#112)
Support {2, 4, 8} for the number of multiple PRACH transmissions with same Tx beams.
R1-2306038 FL Summary#3 on PRACH coverage enhancements Moderator (China Telecom)
From Thursday session
Agreement
For RO group determination for multiple PRACH transmissions, following parameters are considered.
· The candidate number of multiple PRACH transmissions, e.g. {2,4,8}, is/are explicitly configured.
o The number of ROs within one RO group can be implicitly determined accordingly.
o Default value(s) is/are not precluded
· The number of SSB-to-RO association pattern periods K within the time period X, down select from the following options.
o Option 1: K is explicitly configured.
o Option 2: K is implicitly determined
o Option 3: K is a fixed value for all number of multiple PRACH transmissions.
· Determination of starting RO for each RO group for each value of the number of multiple PRACH transmissions, down select from the following options.
o Option 1: Index/indices of the starting RO(s) of the RO group(s) is/are explicitly indicated.
§ FFS: whether other parameters configured by gNB to allow density control and/or RO group(s) position alignment for multiple configured numbers
§ FFS: whether only the starting RO of the first RO group is explicitly indicated, and the starting ROs of the other RO groups are implicitly determined.
§ FFS: other ROs for each RO group
o Option 2: The time start position and the frequency start position of the first valid RO for each RO group are implicitly determined.
§ FFS: other ROs for each RO group
§ FFS: whether other parameters configured by gNB to allow density control and/or RO group(s) position alignment for multiple configured numbers
· FFS: The frequency hopping offset, if frequency hopping is supported.
· FFS: RO group specific preamble if multiple PRACH transmissions with different numbers are transmitted with separate preamble on shared ROs
· FFS: Time span of the RO group
· All other legacy parameters for single PRACH transmission can be reused, if applicable.
R1-2306039 FL Summary#4 on PRACH coverage enhancements Moderator (China Telecom)
From Friday session
Agreement
· For multiple PRACH transmissions with separate preamble on shared ROs, reuse legacy SSB to RO mapping rule, and only the ROs mapped to SSBs for single PRACH transmission can be used for multiple PRACH transmissions.
Agreement
For multiple PRACH transmissions on separate ROs, down-select one of the following options:
· Option 1: SSB-to-RO group mapping is introduced.
· Option 2: Reuse legacy SSB to RO mapping rule.
R1-2304504 Discussions on remaining issues of power domain enhancements vivo
R1-2304581 Discussion on power domain enhancements Spreadtrum Communications
R1-2304599 Discussion on power domain enhancements ZTE
R1-2304650 Discussion on coverage enhancement in power domain Huawei, HiSilicon
R1-2304718 Discussion on MPR/PAR reduction enhancements CATT
R1-2304776 Discussion on Power domain enhancements Fujitsu
R1-2304808 Discussions on power domain enhancement Intel Corporation
R1-2304866 Discussion on power domain enhancements China Telecom
R1-2304885 Discussion on power domain enhancements xiaomi
R1-2304976 Power domain enhancements Lenovo
R1-2305116 Discussion on power domain enhancements CMCC
R1-2305137 RAN1 impacts for power domain enhancements Nokia, Nokia Shanghai Bell
R1-2305272 Discussion on power domain coverage enhancement Apple
R1-2305307 Discussion on power domain enhancements Panasonic
R1-2305362 Power-domain enhancements Qualcomm Incorporated
R1-2305393 Discussion on Power Domain Enhancements LG Electronics
R1-2305454 The study of power domain enhancements OPPO
R1-2305484 Power Domain Enhancement Schemes and Performance Ericsson
R1-2305539 Power domain enhancements Samsung
R1-2305617 Discussion on power domain enhancements NTT DOCOMO, INC.
R1-2305665 Discussion on power domain enhancements MediaTek Inc.
R1-2305808 DMRS design for power domain enhancements Indian Institute of Tech (H)
R1-2305850 Power domain enhancements for Rel-18 CovEnh Sharp
R1-2305859 Discussion on power domain enhancements InterDigital, Inc.
R1-2305913 Discussion on power domain enhancements Google Inc.
R1-2305977 FL summary of power domain enhancements (AI 9.12.2) Moderator (Nokia)
R1-2305978 FL summary #2 of power domain enhancements (AI 9.12.2) Moderator (Nokia)
Presented in Monday session
R1-2305979 FL summary #3 of power domain enhancements (AI 9.12.2) Moderator (Nokia)
From Tuesday session
Agreement
If FDSS-SE is supported in Rel-18, for the case of DMRS sequence length before extension of the sequence, if any, larger than or equal to 30, legacy DMRS sequences are used with FDSS-SE.
RAN1 to down-select in RAN1 #114 only one of the following alternatives:
FFS: the case of DMRS sequence length before extension of the sequence, if any, smaller than 30.
FFS: whether this applies to Low-PAPR Type 2 DMRS
Note: down-selection should be based at least on OBO evaluations, as well as delta(SNR). Other metrics, e.g., PAPR and CM, can also be considered.
Working Assumption
Agreement
Agreement
R1-2306127 FL summary #4 of power domain enhancements (AI 9.12.2) Moderator (Nokia)
From Thursday session
Conclusion
If enhancements to the PHR report are to be specified in Rel-18, at least the following enhancements to the PHR report framework might be potentially useful for realizing high power uplink transmissions in CA and DC:
Discussion continues in RAN1 on whether enhancements to the PHR report are needed in Rel-18.
Working Assumption
If FDSS-SE is supported in Rel-18:
FFS: how the number of PRBs/sub-carriers in the inband and total allocation is determined by the UE, i.e., details about FDRA indication.
R1-2305980 Final FL summary of power domain enhancements (AI 9.12.2) Moderator (Nokia)
R1-2304505 Discussions on remaining issues of dynamic waveform switching vivo
R1-2304582 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Spreadtrum Communications
R1-2304600 Discussion on dynamic waveform switching ZTE
R1-2304651 Discussion on dynamic waveform switching for coverage enhancement Huawei, HiSilicon
R1-2304719 Dynamic switching between DFT-S-OFDM and CP-OFDM CATT
R1-2304799 Dynamic switching between DFT-S-OFDM and CP-OFDM InterDigital, Inc.
R1-2304809 Dynamic switching between DFT-S-OFDM and CP-OFDM waveform Intel Corporation
R1-2304867 Discussion on dynamic waveform switching between DFT-s-OFDM and CP-OFDM China Telecom
R1-2304870 Discussion on dynamic waveform switching Panasonic
R1-2304886 Discussion on dynamic switching between DFT-s-OFDM and CP-OFDM xiaomi
R1-2304977 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Lenovo
R1-2305000 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM NEC
R1-2305054 Considerations on dynamic waveform switching for various PUSCH types Sony
R1-2305117 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM CMCC
R1-2305138 Dynamic switching between DFT-s-OFDM and CP-OFDM Nokia, Nokia Shanghai Bell
R1-2305273 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Apple
R1-2305363 Dynamic switching between DFT-S-OFDM and CP-OFDM Qualcomm Incorporated
R1-2305394 Discussion on dynamic waveform switching for NR coverage enhancement LG Electronics
R1-2305455 Considerations on dynamic switching between DFT-S-OFDM and CP-OFDM OPPO
R1-2305485 Discussion on Dynamic UL Waveform Switching Ericsson
R1-2305540 Dynamic switching between DFT-S-OFDM and CP-OFDM Samsung
R1-2305570 Dynamic switching between DFT-S-OFDM and CP-OFDM for Rel-18 CovEnh Sharp
R1-2305618 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM NTT DOCOMO, INC.
R1-2305666 Dynamic switching between waveforms MediaTek Inc.
R1-2305682 Discussion on solutions for NR dynamic switching between DFT-S-OFDM and CP-OFDM Mavenir
R1-2305714 Discussion of dynamic switching between DFT-S-OFDM and CP-OFDM Transsion Holdings
R1-2305803 Dynamic switching between DFT-S-OFDM and CP-OFDM ETRI
R1-2305914 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Google Inc.
R1-2305477 Summary #1 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
R1-2305478 Summary #2 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From Tuesday session
Agreement
Configuration of dynamic waveform switching indicator field, for a BWP, is separately configurable between DCI format 0_1 and DCI format 0_2.
Agreement
For potential enhancements to assist the scheduler in determining waveform switching, RAN1 to select 1 from the following options:
· Option 1: Reporting of power headroom information for a reference PUSCH using target waveform different from waveform of actual PUSCH.
o Details FFS.
§ Note: Any MAC CE related decision is up to RAN2
· Option 4: No enhancement.
R1-2305479 Summary #3 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
R1-2306239 Summary #4 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
Final summary in R1-2306255.
Please refer to RP-221858 for detailed scope of the WI on further NR coverage enhancements. Rapporteur to provide initial input on higher layer signalling under agenda item 9.12. For input on higher layer signalling from any other source, please include it as part of your tdoc to relevant sub-agenda items.
R1-2308549 Session notes for 9.12 (Further NR coverage enhancements) Ad-Hoc Chair (CMCC)
Endorsed and contents incorporated below.
[114-R18-CovEnh] – Nanxi (China Telecom)
Email discussion on coverage enhancement
- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2307857 Initial higher layer parameter list for Rel-18 coverage enhancements Rapporteur (China Telecom)
R1-2308679 RAN1 agreements for Rel-18 WI on Further NR coverage enhancements Rapporteur (China Telecom)
R1-2306406 Discussions on PRACH coverage enhancements New H3C Technologies Co., Ltd.
R1-2306545 Discussion on PRACH coverage enhancements Huawei, HiSilicon
R1-2306580 Discussions on PRACH coverage enhancements Ruijie Network Co. Ltd
R1-2306667 Discussion on PRACH coverage enhancements Spreadtrum Communications
R1-2306701 PRACH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2306772 Discussions on remaining issues of PRACH coverage enhancements vivo
R1-2306825 Discussions on PRACH coverage enhancement Intel Corporation
R1-2306858 Discussion on PRACH coverage enhancements Panasonic
R1-2306894 Discussion on PRACH repeated transmission for NR coverage enhancement LG Electronics
R1-2306923 Remaining issues on multiple PRACH transmissions for PRACH coverage enhancement Sony
R1-2306984 Discussion on PRACH coverage enhancements ZTE
R1-2307065 PRACH coverage enhancements CATT
R1-2307135 Discussion on PRACH coverage enhancement NEC
R1-2307165 Discussion on PRACH coverage enhancements Fujitsu
R1-2307217 Discussion on PRACH coverage enhancements CMCC
R1-2307224 Discussion on PRACH coverage enhancements Quectel
R1-2307305 Discussion on PRACH coverage enhancement Apple
R1-2307358 Discussion on PRACH coverage enhancements xiaomi
R1-2307412 PRACH coverage enhancements Lenovo
R1-2307434 Multiple PRACH transmissions for Rel-18 CovEnh Sharp
R1-2307492 Discussion on PRACH coverage enhancements NTT DOCOMO, INC.
R1-2307558 PRACH coverage enhancements OPPO
R1-2307596 PRACH coverage enhancements TCL
R1-2307626 Discussion on PRACH coverage enhancement China Telecom
R1-2307632 Discussion on PRACH coverage enhancements Google Inc.
R1-2307702 PRACH coverage enhancements Samsung
R1-2307727 Discussion on PRACH coverage enhancement Mavenir
R1-2307753 PRACH coverage enhancements ETRI
R1-2307844 Discussion on PRACH Coverage Enhancement Ericsson
R1-2307871 Discussion on PRACH coverage enhancements InterDigital, Inc.
R1-2307951 PRACH Coverage Enhancements Qualcomm Incorporated
R1-2308060 PRACH coverage enhancements MediaTek Inc.
R1-2308308 FL Summary#1 on PRACH coverage enhancements Moderator (China Telecom)
From Monday session
Agreement
For multiple PRACH transmissions on separate ROs, reuse legacy SSB to RO mapping rule.
R1-2308309 FL Summary#2 on PRACH coverage enhancements Moderator (China Telecom)
From Tuesday session
Agreement
For a given number of N multiple PRACH transmissions, all the RO groups within a time period X are determined as follows:
o Alt.1 (w/o density control)
o Alt.2 (w/ density control)
is determined
from the first valid RO within the time period X, first in increasing
order of frequency resource index for frequency multiplexed PRACH
occasions; second in increasing order of time resource index. is determined as
the RO at the time offset equal to a number of valid ROs from the
starting RO of the (n-1)-th RO group for the same .
R1-2308310 FL Summary#3 on PRACH coverage enhancements Moderator (China Telecom)
From Thursday session
Agreement
Add the following notes to the above agreement:
Note1: “the starting RO of other RO groups are determined as the first valid RO after the previous RO group in the following order within the time period X: first, in increasing order of frequency resource indexes for frequency multiplexed PRACH occasions; second, in increasing order of time resource indexes.” is illustrated as in the following figure (N=2, for ROs associated with SSB#0). This works for both Alt.1 and Alt.2 for the starting RO determination.
Note2: all the ROs mentioned in the agreement are valid ROs associated with the given same SSB(s) and all the RO groups mentioned in the agreement are RO groups consisting of valid ROs associated with the given same SSB(s).
Note3:
of an RO, frequency
resource index of an RO, and the starting RB of an RO indicate the same
meaning, i.e., locate in the same frequency position.
Conclusion
For multiple PRACH transmissions with the same Tx beam, the two transmission power determination equations (just for reference: equation (1) and (2) as shown in the reference) of Rel-17 NR PRACH are reused for calculating the transmission power of each PRACH transmission, i.e.,
PREAMBLE_RECEIVED_TARGET_POWER = preambleInitialReceivedTargetPower + DELTA_PREAMBLE + (PREAMBLE_TRANSMISSION_COUNTER – 1) * powerRampingStep.
Note: The following is for reference.
|
For reference: The power control formula of NR PRACH consists of the following two steps: Step 1: Calculate the receive target power of one single transmission. PREAMBLE_RECEIVED_TARGET_POWER=preambleInitialReceivedTargetPower+DELTA_PREAMBLE + (PREAMBLE_TRANSMISSION_COUNTER – 1) * powerRampingStep (1) Step 2: Calculate the transmission power of single transmission. P_PRACH = min{P_CMAX(i), PREAMBLE_RECEIVED_TARGET_POWER + PL_c} [dBm] (2) |
Agreement
For a given number of N multiple PRACH transmissions, to determine the starting RO of all the RO groups within a time period X:
is determined
from the first valid RO within the time period X, first in increasing
order of frequency resource index for frequency multiplexed PRACH
occasions; second in increasing order of time resource index. is determined as
the RO at the time offset equal to a number of valid ROs from the
starting RO of the (n-1)-th RO group for the same .
R1-2308311 FL Summary#4 on PRACH coverage enhancements Moderator (China Telecom)
From Friday session
Agreement
For the number of SSB-to-RO association pattern periods K within the time period X,
· For multiple PRACH transmissions with different numbers, support
One common K
is implicitly determined as a minimum integer for all the configured number of
multiple PRACH transmissions such that for each of 
SSBs, there is at least one RO group per each configured number of
multiple PRACH transmissions consisting of ROs associated with the SSB.
Agreement
For a given number of N multiple PRACH transmissions, the remaining N-1 ROs are the next N-1 ROs after the starting RO with increasing order of time resource indexes and associated with the same SSB(s) as the starting RO, to determine the remaining N-1 ROs:
· the N-1 ROs are with the same starting RB as the starting RO.
Consider additional RAN agreement from RAN#100 (RP-231498, proposal 1).
R1-2306546 Discussion on coverage enhancement in power domain Huawei, HiSilicon
R1-2306581 Discussions on power domain enhancements Ruijie Network Co. Ltd
R1-2306668 Discussion on power domain enhancements Spreadtrum Communications
R1-2306702 RAN1 impacts for power domain enhancements Nokia, Nokia Shanghai Bell
R1-2306773 Discussions on remaining issues of power domain enhancements vivo
R1-2306895 Discussion on Power Domain Enhancements LG Electronics
R1-2306985 Discussion on power domain enhancements ZTE
R1-2307166 Discussion on power domain enhancements Fujitsu
R1-2307218 Discussion on power domain enhancements CMCC
R1-2307306 Discussion on power domain coverage enhancement Apple
R1-2307359 Discussion on power domain enhancements xiaomi
R1-2307413 Power domain enhancements Lenovo
R1-2307435 Power domain enhancements for Rel-18 CovEnh Sharp
R1-2307493 Discussion on power domain enhancements NTT DOCOMO, INC.
R1-2307559 The study of power domain enhancements OPPO
R1-2307703 Power domain enhancements Samsung
R1-2307845 Finalization of Power Domain Enhancement Schemes Ericsson
R1-2307872 Discussion on power domain enhancements InterDigital, Inc.
R1-2307952 Power-domain enhancements Qualcomm Incorporated
R1-2308061 Power domain enhancements MediaTek Inc.
R1-2308238 FL summary of power domain enhancements (AI 9.12.2) Moderator (Nokia)
From Monday session
Conclusion
No further discussion related to enhancements for reducing MPR/PAR objective in RAN1 in Rel-18.
R1-2308560 [Draft] LS on further clarifications on enhancements to realize increasing UE power high limit for CA and DC Moderator (Nokia)
Decision from Thursday session: Draft LS R1-2308560 is endorsed in principle by removing Q5. Final LS is approved in R1-2308561.
Final summary in R1-2308240.
Consider additional RAN agreement from RAN#100 (RP-231498, proposal 2). RAN1 will make decision on whether to define any PHR enhancement for Rel-18 on the first day of RAN1#114.
R1-2306547 Discussion on dynamic waveform switching for coverage enhancement Huawei, HiSilicon
R1-2306582 Discussions on dynamic switching between DFT-S-OFDM and CP-OFDM Ruijie Network Co. Ltd
R1-2306669 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Spreadtrum Communications
R1-2306703 Dynamic switching between DFT-s-OFDM and CP-OFDM Nokia, Nokia Shanghai Bell
R1-2306774 Discussions on remaining issues of dynamic waveform switching vivo
R1-2306826 Dynamic switching between DFT-S-OFDM and CP-OFDM waveform Intel Corporation
R1-2306896 Discussion on dynamic waveform switching for NR coverage enhancement LG Electronics
R1-2306924 Remaining issues on dynamic waveform switching Sony
R1-2306986 Discussion on dynamic waveform switching ZTE
R1-2307005 Discussion on dynamic waveform switching Panasonic
R1-2307066 Dynamic switching between DFT-S-OFDM and CP-OFDM CATT
R1-2307136 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM NEC
R1-2307219 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM CMCC
R1-2307253 Dynamic switching between DFT-S-OFDM and CP-OFDM InterDigital, Inc.
R1-2307307 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Apple
R1-2307360 Discussion on dynamic switching between DFT-s-OFDM and CP-OFDM xiaomi
R1-2307414 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Lenovo
R1-2307436 Dynamic switching between DFT-S-OFDM and CP-OFDM for Rel-18 CovEnh Sharp
R1-2307494 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM NTT DOCOMO, INC.
R1-2307560 Considerations on dynamic switching between DFT-S-OFDM and CP-OFDM OPPO
R1-2307627 Discussion on dynamic waveform switchin between DFT-s-OFDM and CP-OFDM China Telecom
R1-2307633 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Google Inc.
R1-2307704 Dynamic switching between DFT-S-OFDM and CP-OFDM Samsung
R1-2307726 Discussion on solutions for NR dynamic switching between DFT-S-OFDM and CP-OFDM Mavenir
R1-2307754 Dynamic switching between DFT-S-OFDM and CP-OFDM ETRI
R1-2307769 Discussion of dynamic switching between DFT-S-OFDM and CP-OFDM Transsion Holdings
R1-2307846 Discussion on Dynamic UL Waveform Switching Ericsson
R1-2307953 Dynamic switching between DFT-S-OFDM and CP-OFDM Qualcomm Incorporated
R1-2308062 Dynamic waveform switching MediaTek Inc.
R1-2308013 Summary #1 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From Monday session
Agreement
Support following enhancement to assist the scheduler in determining waveform switching:
Conclusion (Made in RAN#100, RP-231498)
RAN2 will not work on PHR triggering procedure for dynamic waveform switching in Rel-18 UL Coverage enh WI
Send LS to inform above agreement and conclusion.
R1-2308364 Draft LS on Reporting of power headroom information for an assumed PUSCH Moderator (InterDigital, Inc.)
Decision: The draft LS is endorsed in principle. Final LS is approved in R1-2308376.
R1-2308014 Summary #2 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From Tuesday session
Agreement
Introduce two new RRC parameters for configuration of DWS field in DCI formats 0_1/0_2:
R1-2308015 Summary #3 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From Thursday session
Agreement
For reporting of power headroom information for assumed PUSCH using target waveform different from waveform of actual PUSCH, support the following:
Send LS to RAN2 to inform above agreement.
R1-2308476 Draft LS on Details of power headroom information for assumed PUSCH Moderator (InterDigital, Inc.)
Decision: Draft LS R1-2308476 is endorsed in principle by adding above agreement. Final LS is approved in R1-2308477.
Agreement
Introduce a new RRC parameter under PHR-Config for configuration of reporting of power headroom information for an assumed PUSCH:
Value range is {enabled}.
Agreement
Value “0” of dynamic waveform switching indicator field maps to transform precoding enabled.
Value “1” of dynamic waveform switching indicator field maps to transform precoding disabled.
Final summary in R1-2308478.
R1-2310546 Session notes for 8.8 (Maintenance on further NR coverage enhancements) Ad-Hoc Chair (CMCC)
Friday decision: The session notes are endorsed and contents reflected below.
[114bis-R18-CovEnh] – Nanxi (China Telecom)
Email discussion on coverage enhancement
- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2308899 Maintenance of PRACH coverage enhancements Huawei, HiSilicon
R1-2308953 Discussions on the remaining issue on PRACH coverage enhancements New H3C Technologies Co., Ltd.
R1-2308995 Remaining issues on PRACH coverage enhancements Spreadtrum Communications
R1-2309085 Discussions on remaining issues of PRACH coverage enhancements vivo
R1-2309132 Discussion on PRACH coverage enhancements ZTE
R1-2309187 Remaining issues on PRACH coverage enhancement Intel Corporation
R1-2309278 Maintenance on PRACH coverage enhancement NEC
R1-2309329 Remaining issues on PRACH coverage enhancements LG Electronics
R1-2309385 PRACH coverage enhancements Samsung
R1-2309465 Discussion on PRACH coverage enhancements xiaomi
R1-2309536 Remaining issues on PRACH coverage enhancements CATT
R1-2309554 Remaining issues on PRACH coverage enhancement China Telecom
R1-2309612 Remaining issues on PRACH coverage enhancements OPPO
R1-2309633 Discussion on PRACH coverage enhancements Panasonic
R1-2309650 Remaining issues on PRACH coverage enhancement Fujitsu
R1-2309681 Remaining issues on PRACH coverage enhancements CMCC
R1-2309706 PRACH coverage enhancements ETRI
R1-2309731 PRACH coverage enhancements TCL
R1-2309772 Discussions on PRACH coverage enhancements Ruijie Network Co. Ltd
R1-2309804 Remaining issues of PRACH coverage enhancements Lenovo
R1-2309843 Discussion on PRACH coverage enhancements Apple
R1-2309909 Remaining issues on multiple PRACH transmissions for PRACH coverage enhancement Sony
R1-2309924 Remaining issues on PRACH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2309958 Remaining issues on PRACH coverage enhancements InterDigital, Inc.
R1-2309967 Discussion on PRACH Coverage Enhancement Ericsson
R1-2310001 Remaining issues on PRACH coverage enhancements MediaTek Inc.
R1-2310042 Remaining issues on PRACH coverage enhancements NTT DOCOMO, INC.
R1-2310071 Remaining issues on PRACH coverage enhancements Quectel
R1-2310106 Remaining issues on multiple PRACH transmissions for Rel-18 CovEnh Sharp
R1-2310151 PRACH Coverage Enhancements Qualcomm Incorporated
R1-2310303 FL Summary #1 on remaining issues for PRACH coverage enhancements Moderator (China Telecom)
From Monday session
Agreement
· TimeOffsetBetweenStartingRO-r18 is configured separately for each configured number of multiple PRACH.
Agreement
· Adopt the following revision on RRC parameter.
|
Sub-feature group |
Description |
Value range |
Default value aspect |
Per (UE, cell, TRP, …) |
|
multiple PRACH transmissions |
The number of preamble repetitions for a PRACH transmission |
{2, 4, 8} |
|
|
Agreement
· Adopt the following TP to Section 8.1, TS 38.213
|
8.1 Random access preamble Physical random access procedure for a UE is triggered upon request of a PRACH transmission by higher layers or by a PDCCH order for a cell. A configuration by higher layers for a PRACH transmission includes the following: - A configuration for PRACH transmission on the cell [4, TS 38.211]. - A
preamble index, a preamble SCS, - A
number of A
UE transmits a PRACH on a cell using the selected PRACH format with
transmission power < Unchanged text omitted > |
R1-2310304 FL Summary #2 on remaining issues for PRACH coverage enhancements Moderator (China Telecom)
From Tuesday session
Agreement
Adopt the TP to Section 8.1, TS 38.213 exactly same as the FL proposal 1-6 proposed in R1-2310304 by adding parenthesis to the s of sets of “sets of valid PRACH”.
Agreement
· Adopt the following TP to Section 8.1, TS 38.213.
|
8.1 Random access preamble *** Unchanged parts are omitted *** A PRACH is transmitted
using the selected PRACH format with transmission power *** Unchanged parts are omitted *** For a PRACH
transmission with *** Unchanged parts are omitted *** |
Agreement
The candidate value of TimeOffsetBetweenStartingRO-r18 is proposed as below
· {16, [32]}, for RO groups for 8 repetitions
· {8, 16, [32]}, for RO groups for 4 repetitions
· {4, 8, [16, 32]}, for RO groups for 2 repetitions
R1-2310305 FL Summary #3 on remaining issues for PRACH coverage enhancements Moderator (China Telecom)
From Thursday session
Agreement
All ROs in one RO group are associated with the same SSB(s), which means:
· If each RO is associated with one SSB, all ROs in one RO group are associated with the same SSB index.
·
If each
RO is associated with multiple SSB, all ROs in one RO
group are associated with the same SSB indexes and each same SSB index of the SSB indexes is
associated with the same preambles.
Note: Potential spec. impact will be further investigated.
Agreement
· Adopt the following TP to Section 8.1, TS 38.213.
|
8.1 Random access preamble *** Unchanged parts are omitted *** Within a time
period, - if TimeOffsetBetweenStartingRO is provided, for each frequency resource index for frequency multiplexed PRACH occasions, - the
first valid PRACH occasion of the first set - the
first valid PRACH occasion of subsequent sets, if any, - otherwise, - the
first valid PRACH occasion of the first set - the
first valid PRACH occasion of subsequent sets - first, in increasing order of frequency resource indexes for frequency multiplexed PRACH occasions - second, in increasing order of time resource indexes for time multiplexed PRACH occasions *** Unchanged parts are omitted *** |
Note: the empty parts in the TP are deleted equations.
Conclusion
For multiple PRACH transmission with the
same Tx beam, the equation of
Rel-17 NR PRACH as follows 
is
reused for calculating the transmission power of each PRACH transmission, where
stands for the
corresponding transmission occasion of each of
the multiple PRACH transmissions.
For the editors:
The above endorsed text proposals to 38.213 are also collected in R1-2310486. Please consider them in the next specification revision.
R1-2310486 Collection of endorsed TPs in AI 8.8.1 PRACH coverage enhancements Moderator (China Telecom)
Final summary in R1-2310579.
R1-2308900 Discussion on coverage enhancement in power domain Huawei, HiSilicon
R1-2309086 Discussions on remaining issues of power domain enhancements vivo
R1-2309188 Remaining issues on power domain enhancement Intel Corporation
R1-2309386 Power domain enhancements Samsung
R1-2309466 Maintenance on power domain enhancements xiaomi
R1-2309537 RAN1 impact for power domain enhancement CATT
R1-2309555 Remaining issues on power domain enhancements China Telecom
R1-2309613 Remaining issues on of power domain enhancements OPPO
R1-2309682 Remaining issues on power domain enhancements CMCC
R1-2309914 Discussion on power domain enhancements ZTE
R1-2309925 Remaining issues on power domain enhancements Nokia, Nokia Shanghai Bell
R1-2309968 Power Domain Enhancement Maintenance Ericsson
R1-2310152 Power-domain enhancements Qualcomm Incorporated
R1-2310300 FL summary of power domain enhancements (AI 8.8.2) Moderator (Nokia)
From Monday session
Conclusion
No RAN1 specification impact to realize the inclusion of ΔPPowerClass in a report to network.
RAN1 further discuss potential RAN1 impact concerning support for uplink full power MIMO transmission dependency on ΔPPowerClass report.
R1-2310301 FL summary #2 of power domain enhancements (AI 8.8.2) Moderator (Nokia)
From Tuesday session
Agreement
RAN1 to send a response LS to RAN4 taking the following conclusion as a starting point:
|
Conclusion: No RAN1 specification impact to realize the inclusion of ΔPPowerClass in a report to network. RAN1 further discuss potential RAN1 impact concerning support for uplink full power MIMO transmission dependency on ΔPPowerClass report. |
Conclusion
For potential RAN1 impacts on how UL full-power capability vary with ΔPPowerClass reporting, continue to discuss the following:
· Potential modifications to the scale factor ‘s’ in 38.213 subclause 7.1 to depend on ΔPPowerClass.
· Modifications related to TPMI e.g., modifications to avoid erroneous TPMI configuration and modifications to the TPMI table description
· Potential impact of ΔPPowerClass on maximal number of layers in MIMO
From Thursday session
R1-2310489 Draft reply LS on RAN1 impacts regarding enhancements to realize increasing UE power high limit for CA and DC Nokia
Decision: Draft LS R1-2310489 is endorsed in principle. Final LS is approved in R1-2310518.
Final summary in R1-2310302.
R1-2308901 Maintenance of dynamic waveform switching for coverage enhancement Huawei, HiSilicon
R1-2308996 Remaining issues on dynamic switching between DFT-S-OFDM and CP-OFDM Spreadtrum Communications
R1-2309087 Discussions on remaining issues of dynamic waveform switching vivo
R1-2309133 Discussion on dynamic waveform switching ZTE
R1-2309189 Remaining issues on dynamic waveform switching Intel Corporation
R1-2309279 Maintenance on dynamic switching between DFT-S-OFDM and CP-OFDM NEC
R1-2309330 Remaining issues on dynamic waveform switching for NR coverage enhancement LG Electronics
R1-2309387 Dynamic switching between DFT-S-OFDM and CP-OFDM Samsung
R1-2309467 Maintenance on dynamic switching between DFT-s-OFDM and CP-OFDM xiaomi
R1-2309538 Remaining issues on dynamic switching between DFT-S-OFDM and CP-OFDM CATT
R1-2309556 Remaining issues on dynamic waveform switching between DFT-s-OFDM and CP-OFDM China Telecom
R1-2309614 Issues on dynamic switching between DFT-S-OFDM and CP-OFDM OPPO
R1-2309630 Discussion on the remaining issues for dynamic waveform switching Panasonic
R1-2309683 Remaining issues on dynamic switching between DFT-S-OFDM and CP-OFDM CMCC
R1-2309707 Dynamic switching between DFT-S-OFDM and CP-OFDM ETRI
R1-2309722 Remaining issues of dynamic switching between DFT-S-OFDM and CP-OFDM Transsion Holdings
R1-2309729 Remaining issues on dynamic switching between DFT-S-OFDM and CP-OFDM Lenovo
R1-2309783 Dynamic switching between DFT-S-OFDM and CP-OFDM InterDigital, Inc.
R1-2309844 Discussion on dynamic switching between DFT-S-OFDM and CP-OFDM Apple
R1-2309910 Maintenance Issues on DWS Configuration and PHR reporting Sony
R1-2309926 Remaining issues on dynamic switching between DFT-s-OFDM and CP-OFDM Nokia, Nokia Shanghai Bell
R1-2309969 Discussion on Dynamic UL Waveform Switching Ericsson
R1-2310043 Remaining issues on dynamic switching between DFT-S-OFDM and CP-OFDM NTT DOCOMO, INC.
R1-2310107 Remaining issues on dynamic waveform switching for Rel-18 CovEnh Sharp
R1-2310153 Dynamic switching between DFT-S-OFDM and CP-OFDM Qualcomm Incorporated
R1-2310248 Summary #1 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From Monday session
Agreement
· Adopt following changes to Section 7.3.1.1.2, TS 38.212 v18.0.0
7.3.1.1.2 Format 0_1
<<< Start changes >>>
- Transform precoder indicator - 0 or 1 bit
- 1 bit if the higher layer parameter dynamicTransformPrecoderIndicationDCI-0-1 is configured to 'enabled ' and if the UE is configured to monitor DCI format 0_1 with CRC scrambled by C-RNTI or CS-RNTI or MCS-C-RNTI, where the bit value of 0 indicates that transform precoder is enabled and the bit value of 1 indicates that transform precoder is disabled. For a DCI format 0_1 with CRC scrambled by CS-RNTI and the value indicated by new data indicator field is 0, or for a DCI format 0_1 with CRC scrambled by SP-CSI-RNTI, the bit is reserved.
- 0 bit otherwise.
<<< End changes >>>
Agreement
· Adopt following changes to Section 7.3.1.1.3, TS 38.212 v18.0.0
7.3.1.1.3 Format 0_2
<<< Start changes >>>
- Transform precoder indicator - 0 or 1 bit
- 1 bit if the higher layer parameter dynamicTransformPrecoderIndicationDCI-0-2 is configured to 'enabled ' and if the UE is configured to monitor DCI format 0_2 with CRC scrambled by C-RNTI or CS-RNTI or MCS-C-RNTI, where the bit value of 0 indicates that transform precoder is enabled and the bit value of 1 indicates that transform precoder is disabled. For a DCI format 0_2 with CRC scrambled by CS-RNTI and the value indicated by new data indicator field is 0, or for a DCI format 0_2 with CRC scrambled by SP-CSI-RNTI, the bit is reserved.
- 0 bit otherwise.
<<< End changes >>>
R1-2310249 Summary #2 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From Tuesday session
Agreement
The following changes to Section 7.3.1.1.2, TS 38.212 v18.0.0 is endorsed in principle.
- DMRS sequence initialization – 0 bit if transform precoder is enabled by higher layers and the Transform precoder indicator field is not present; 1 bit if transform precoder is disabled by higher layers or if the Transform precoder indicator field is present. If the Transform precoder indicator field is present and set to ‘0’, the bit is reserved.
Agreement
The following changes to Section 7.3.1.1.3, TS 38.212 v18.0.0 is endorsed in principle.
- DMRS sequence initialization – 0 or 1 bit
o 0 bit if the higher layer parameter dmrs-SequenceInitializationDCI-0-2 is not configured, or if transform precoder is enabled by higher layers and the Transform precoder indicator field is not present;
- 1 bit if transform precoder is disabled by higher layers and the higher layer parameter dmrs-SequenceInitializationDCI-0-2 is configured, or if the Transform precoder indicator field is present and the higher layer parameter dmrs-SequenceInitializationDCI-0-2 is configured. If the Transform precoder indicator field is present and set to ‘0’, the bit is reserved.
R1-2310456 Summary #3 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From Thursday session
For the editors:
The above endorsed text proposals to 38.212 are also collected in R1-2310499. Please consider them in the next specification revision.
R1-2310499 Collection of endorsed TPs in AI 8.8.3 Dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
Conclusion
In Rel-18, for msg3 PUSCH and msgA PUSCH, the UE considers the transform precoding 'enabled' or 'disabled' according to legacy.
Agreement
For PUSCH scheduled by DCI format 0_1 (0_2) in PDCCH with CRC scrambled with C-RNTI, MCS-C-RNTI, or CS-RNTI with NDI=1 and [dynamicTransformPrecoderIndicationDCI-0-1] ([dynamicTransformPrecoderIndicationDCI-0-2]) set to ‘enabled’:
· If higher layers and/or DCI set uplink resource allocation to type 0, UE does not expect that Transform precoder indicator field indicates that transform precoder is enabled.
· Note: further investigate any specification change.
Agreement
For PUSCH scheduled by DCI format 0_1 (0_2) in PDCCH with CRC scrambled with C-RNTI, MCS-C-RNTI, or CS-RNTI with NDI=1 and [dynamicTransformPrecoderIndicationDCI-0-1] ([dynamicTransformPrecoderIndicationDCI-0-2]) set to ‘enabled’:
· If dmrs-Type corresponding to the PUSCH is set to type2, UE does not expect that Transform precoder indicator field indicates that transform precoder is enabled.
· Note: further investigate any specification change.
Final summary in R1-2310457.
R1-2312507 Session notes for 8.8 (Maintenance on further NR coverage enhancements) Ad-Hoc Chair (Huawei)
Friday decision: The session notes are endorsed and contents reflected below.
[115-R18-CovEnh] – Nanxi (China Telecom)
Email discussion on coverage enhancement
- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2310882 Maintenance of PRACH coverage enhancements Huawei, HiSilicon
R1-2310930 Discussions on the remaining issue on PRACH coverage enhancements New H3C Technologies Co., Ltd.
R1-2311019 Maintenance of PRACH coverage enhancements ZTE
R1-2311054 Remaining issues on PRACH coverage enhancements Fujitsu
R1-2311107 Discussions on remaining issues of PRACH coverage enhancements vivo
R1-2311134 Remaining issues on PRACH coverage enhancement Intel Corporation
R1-2311174 Remaining issues on PRACH coverage enhancements Spreadtrum Communications
R1-2311263 Remaining issues on PRACH coverage enhancements OPPO
R1-2311352 Remaining issues on PRACH coverage enhancements CATT
R1-2311410 Discussion on PRACH coverage enhancements xiaomi
R1-2311426 Maintenance on PRACH coverage enhancement NEC
R1-2311444 Discussion on PRACH coverage enhancements Panasonic
R1-2311492 Remaining issues on PRACH coverage enhancements CMCC
R1-2311526 Remaining issues on multiple PRACH transmissions for PRACH coverage enhancement Sony
R1-2311548 Remaining issues on PRACH coverage enhancement China Telecom
R1-2311631 Remaining issues on PRACH coverage enhancements NTT DOCOMO, INC.
R1-2311694 Remaining issues on PRACH coverage enhancements Apple
R1-2311717 Remaining issues on PRACH coverage enhancements Quectel
R1-2311723 Remaining issues on PRACH coverage enhancements Lenovo
R1-2311755 PRACH coverage enhancements ETRI
R1-2311770 Remaining issues on multiple PRACH transmissions for Rel-18 CovEnh Sharp
R1-2311854 PRACH coverage enhancements Samsung
R1-2311915 Remaining issues on PRACH coverage enhancements LG Electronics
R1-2311920 Remaining issues on PRACH coverage enhancements Nokia, Nokia Shanghai Bell
R1-2311935 Maintenance on PRACH coverage enhancements Ruijie Network Co. Ltd
R1-2311945 Discussion on PRACH Coverage Enhancement Ericsson
R1-2311986 Maintenance for PRACH coverage enhancements MediaTek Inc.
R1-2312132 Remaining issues on PRACH coverage enhancements Google Inc.
R1-2312272 FL Summary #1 on remaining issues for PRACH coverage enhancements Moderator (China Telecom)
From Tuesday session
Agreement
The candidate values of TimeOffsetBetweenStartingRO-r18 are updated as
·
{16, },
for RO groups for 8 repetitions[32]
·
{8, 16, },
for RO groups for 4 repetitions[32]
·
{4, 8, [16, 32]}, for RO groups for 2 repetitions
Agreement
Proposed TP #1-1 in section 4 of R1-2312272 is endorsed.
R1-2312273 FL Summary #2 on remaining issues for PRACH coverage enhancements Moderator (China Telecom)
From Wednesday session
Agreement (superseded by the agreement made on Friday
– see below)
Draft TP #1-5 in section 5 of R1-2312273 is endorsed.
Conclusion
A
set is not determined if the number of valid PRACH occasions after a first
valid PRACH occasion is less than 
-1.
Agreement
The TP below is endorsed in principle for TS 38.213 and an additional new UE capability is introduced for the UE behaviour introduced by this TP.
Note1: editor can provide revisions for the TP below to avoid impacts on any feature other than Rel-18 PRACH repetitions.
|
8.1 Random access preamble *** Unchanged parts are omitted *** For
single cell operation or for operation with contiguous carrier aggregation in
a same frequency band or for operation with non-contiguous carrier
aggregation in a same frequency band if the UE is not provided with intraBandNC-PRACH-simulTx-r17,
a UE does not transmit PRACH and PUSCH/PUCCH/SRS in a same slot with respect
to the smallest SCS configuration between the SCS configuration for the UL
BWP with the PRACH and the SCS configuration for the UL BWP with the
PUSCH/PUCCH/SRS transmissions *** Unchanged parts are omitted *** |
· Reasons for changes: Based on the existing agreement, the dropping rule of single PRACH transmission in existing spec. is reused for multiple PRACH transmissions. Further clarification is needed in the spec.
· Summary of change: Dropping rule of single PRACH is extended to multiple PRACH transmissions.
· Consequences if not approved: It may be not clear when applying existing dropping rule of single PRACH transmission to multiple PRACH transmissions.
R1-2312274 FL Summary #3 on remaining issues for PRACH coverage enhancements Moderator (China Telecom)
R1-2312633 FL Summary #4 on remaining issues for PRACH coverage enhancements Moderator (China Telecom)
From Friday session
Agreement
The following agreement in RAN1 #115…
|
Agreement: Draft TP #1-5 in section 5 of R1-2312273 is endorsed. |
… is updated as:
Draft TP #1-5-1 in Section 6 of R1-2312633 is endorsed with the following revision:
· for each frequency resource index for frequency multiplexed PRACH occasions
o
the first valid PRACH occasion of
the first set for this frequency
resource index is
the first valid PRACH occasion
Conclusion
Within
a time period, the first valid PRACH occasion of the first set for a PRACH transmission with 
preamble repetitions, where each PRACH
occasion within the set(s) is associated with the same one or multiple SSB
index(es) and each same SSB index is associated with the same preambles, is the
valid PRACH occasion at the earliest time instance, and with the lowest
frequency resource index for frequency multiplexed PRACH occasions.
Agreement
For PRACH transmissions with preamble repetitions, a transmission occasion refers to a PRACH occasion.
Note: how to capture this in the spec. is up to the editor.
Conclusion
No further discussion of additional rule for the determination of number of PRACH transmissions in RAN1 in Rel-18.
Agreement
For multiple PRACH transmissions, down-select one of the following options at RAN1#116:
· Option 1:
o Layer 1 notifies higher layers to suspend the corresponding power ramping counter when PRACH transmission in all of PRACH occasions are dropped or with reduced transmit power.
o Layer 1 may notify higher layers to suspend the corresponding power ramping counter when PRACH transmission in any of PRACH occasions are dropped or with reduced transmit power.
· Option 1a:
o Layer 1 notifies higher layers to suspend the corresponding power ramping counter when PRACH transmission in all of PRACH occasions are dropped.
o Layer 1 may notify higher layers to suspend the corresponding power ramping counter when PRACH transmission on part of PRACH occasions are dropped or when PRACH transmission in any of PRACH occasions is with reduced transmit power.
· Option 2:
o Layer 1 may notify higher layers to suspend the corresponding power ramping counter when PRACH transmission in at least one PRACH occasion is dropped or with reduced transmit power.
Note: this implies it’s up to UE implementation.
· Option 2a:
o Layer 1 may notify higher layers to suspend the corresponding power ramping counter when PRACH transmission in at least one PRACH occasion is with reduced transmit power.
o Layer 1 notifies higher layers to suspend the corresponding power ramping counter when PRACH transmission in at least one PRACH occasion is dropped.
· Option 3:
o Layer 1 notifies higher layers to suspend the corresponding power ramping counter when PRACH transmission in all of PRACH occasions are dropped.
o Layer 1 may notify higher layers to suspend the corresponding power ramping counter when PRACH transmission in all of PRACH occasions are with reduced transmit power.
Note: whether any of the above options have specification impact is a separate discussion.
Agreement
For multiple PRACH transmissions with indication of PRACH mask index, down-select one of the following options at RAN1#116
· Option 1: UE applies PRACH mask prior to RO group determination. RO group is determined based on the ROs indicated by the PRACH mask index.
·
Option 2: UE applies PRACH mask after RO group determination. UE transmits
PRACH with 
preamble repetitions only on a RO group with all the ROs indicated
by the mask.
·
Option 3: UE applies PRACH mask after RO group determination. UE transmits
PRACH with preamble repetitions only on a RO group where at least one RO of
this RO group is indicated by the mask
· Option 4: UE applies PRACH mask after RO group determination. The PRACH mask index indicates one or multiple RO groups for multiple PRACH transmission.
o
Note: this implies the
PRACH mask index indicates the RO group instead of RO index(es).
Final summary in R1-2312677.
R1-2310883 Discussion on coverage enhancement in power domain Huawei, HiSilicon
R1-2311020 Maintenance of power domain enhancements ZTE
R1-2311108 Discussions on remaining issues of power domain enhancements vivo
R1-2311175 Remaining issues on power domain enhancement Spreadtrum Communications
R1-2311264 Remaining issues on of power domain enhancements OPPO
R1-2311353 Remaining issue on power domain enhancements CATT
R1-2311411 Maintenance on power domain enhancements xiaomi
R1-2311493 Remaining issues on power domain enhancements CMCC
R1-2311549 Remaining issues on Power domain enhancements China Telecom
R1-2311724 Remaining issues on dynamic switching between DFT-S-OFDM and CP-OFDM Lenono
R1-2311855 Power domain enhancements Samsung
R1-2311921 Remaining issues on power domain enhancements Nokia, Nokia Shanghai Bell
R1-2311946 Power Domain Enhancement Maintenance Ericsson
R1-2312046 Power-domain enhancements Qualcomm Incorporated
R1-2312304 FL summary of power domain enhancements (AI 8.8.2) Moderator (Nokia)
R1-2312305 FL summary #2 of power domain enhancements (AI 8.8.2) Moderator (Nokia)
From Friday session
RAN1 concludes all discussions related to enhancements for increasing UE power high limit for CA and DC in Rel-18. No further discussion on any aspect of this enhancement during any future Rel-18 maintenance phase is planned in RAN1, unless further RAN1 discussion is requested by other working groups.
R1-2312306 Final FL summary of power domain enhancements (AI 8.8.2) Moderator (Nokia)
From AI 5
R1-2311005 LS to RAN1 on PHR reporting RAN2, InterDigital
Decision: To be handled in agenda item 8.8.3. To be moderated by Paul (InterDigital).
Agreement
Send Reply LS to RAN2 LS in R1-2311005 stating:
RAN1 would like to thank RAN2 for the LS on PHR reporting.
RAN2 asked if a UE reporting PCMAX for actual and assumed PUSCH to support the DC/CA scenario has any impact to RAN1’s design in addition to that of the single carrier case. RAN1 would like to inform RAN2 that UE reporting PCMAX for actual and assumed PUSCH to support the DC/CA scenario has no additional impact to RAN1 design compared to the single carrier scenario.
Action: RAN1 respectfully asks RAN2 to take the above information into consideration for their work
Comeback for draft LS
R1-2312338 Draft reply LS on PHR reporting Moderator (InterDigital, Inc.)
Wednesday decision: The draft LS in R1-2312338 is endorsed. Final LS is approved in R1-2312339.
R1-2310884 Maintenance of dynamic waveform switching for coverage enhancement Huawei, HiSilicon
R1-2311021 Maintenance of dynamic waveform switching ZTE
R1-2311109 Discussions on remaining issues of dynamic waveform switching vivo
R1-2311135 Remaining issues on dynamic waveform switching Intel Corporation
R1-2311265 Issues on dynamic switching between DFT-S-OFDM and CP-OFDM OPPO
R1-2311354 Remaining issue on dynamic waveform switching CATT
R1-2311412 Maintenance on dynamic switching between DFT-s-OFDM and CP-OFDM xiaomi
R1-2311427 Maintenance on dynamic switching between DFT-S-OFDM and CP-OFDM NEC
R1-2311445 Discussion on the remaining issues for dynamic waveform switching Panasonic
R1-2311494 Remaining issues on dynamic switching between DFT-S-OFDM and CP-OFDM CMCC
R1-2311532 Dynamic switching between DFT-S-OFDM and CP-OFDM InterDigital, Inc.
R1-2311550 Remaining issues on DWS between CP-OFDM and DFT-s-OFDM China Telecom
R1-2311632 Remaining issues on dynamic switching between DFT-S-OFDM and CP-OFDM NTT DOCOMO, INC.
R1-2311695 Remaining issues on dynamic switching between DFT-S-OFDM and CP-OFDM Apple
R1-2311756 Dynamic switching between DFT-S-OFDM and CP-OFDM ETRI
R1-2311771 Remaining issues on dynamic waveform switching for Rel-18 CovEnh Sharp
R1-2311856 Dynamic switching between DFT-S-OFDM and CP-OFDM Samsung
R1-2311916 Remaining issues on dynamic waveform switching for NR coverage enhancement LG Electronics
R1-2311922 Remaining issues on dynamic switching between DFT-s-OFDM and CP-OFDM Nokia, Nokia Shanghai Bell
R1-2311947 Discussion on Dynamic UL Waveform Switching Ericsson
R1-2312047 Dynamic switching between DFT-S-OFDM and CP-OFDM Qualcomm Incorporated
R1-2312158 Maintenance issues on DWS Configuration Sony
R1-2312205 Remaining issues on dynamic switching between DFT-S-OFDM and CP-OFDM Google Inc.
R1-2312109 Summary #1 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
From Tuesday session
Agreement
Update value range of RRC parameters for presence of TPI field to Enumerated {enabled}.
R1-2312111 Summary #2 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
Presented in Wednesday session.
R1-2312622 Summary #3 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital, Inc.)
Presented in Friday session.
Final summary in R1-2312623.
R1-2401761 Session notes for 8.6 (Maintenance on further NR coverage enhancements) Ad-Hoc Chair (CMCC)
Friday decision: The session notes are endorsed and contents reflected below.
[116-R18-CovEnh] – Nanxi (China Telecom)
Email discussion on coverage enhancement
- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2401500 FL summary of Maintenance on further NR coverage enhancements (AI 8.6) - Power domain enhancements Moderator (Nokia)
Revised in final summary in R1-2401850.
R1-2400159 Discussions on the remaining issue on PRACH coverage New H3C Technologies Co., Ltd.
R1-2400359 Maintenance on Further NR Coverage Enhancements TCL
R1-2400458 Maintenance on PRACH coverage enhancement NEC
R1-2400541 Discussion on PRACH coverage enhancements xiaomi
R1-2400593 Discussion on maintenance on coverage enhancement OPPO
R1-2400992 Remaining issues on further NR coverage enhancements Apple
R1-2401166 Remaining issues on Further NR Coverage Enhancements Sharp
R1-2401207 Remaining issues on PRACH coverage enhancements Fujitsu
R1-2401221 Maintenance on further NR coverage enhancements ETRI
R1-2401313 On maintenance for coverage enhancements MediaTek Inc.
R1-2400039 Remaining issues on further NR coverage enhancements Spreadtrum Communications
R1-2400112 Maintenance of Rel-18 Coverage Enhancements Huawei, HiSilicon
R1-2400222 Maintenance on Further NR Coverage Enhancements vivo
R1-2400292 Maintenance of Rel-18 coverage enhancements ZTE
R1-2400368 Remaining issues on further NR coverage enhancement Intel Corporation
R1-2400411 Remaining issues on Rel-18 coverage enhancements CATT
R1-2400655 Remaining issues on PRACH coverage enhancement China Telecom
R1-2400706 Maintenance on Further NR Coverage Enhancements Samsung
R1-2400809 Remaining issues on further NR coverage enhancements Nokia, Nokia Shanghai Bell
R1-2400829 Maintenance on further NR coverage enhancements Panasonic
R1-2400925 Remaining issues on dynamic switching between DFT-S-OFDM and CP-OFDM InterDigital, Inc.
R1-2401076 Maintenance of Further NR Coverage Enhancements Ericsson
R1-2401094 Maintenance on Further NR Coverage Enhancements NTT DOCOMO, INC.
R1-2401248 Remaining issues on Rel-18 NR coverage enhancements LG Electronics
R1-2401420 Maintenance on Further NR Coverage Enhancements Qualcomm Incorporated
R1-2401553 FL Summary #1 on remaining issues for PRACH coverage enhancements Moderator (China Telecom)
Agreement
Replace TimeOffsetBetweenStartingRO in TS 38.213 by msg1-RepetitionTimeOffsetROGroup to align the RRC parameter name.
Agreement
· Adopt the following TP to Section 8.1, TS 38.213.
|
Reasons for changes: Based on the existing agreement, the dropping rule of single PRACH transmission in existing spec. is extended to each actual PRACH transmission within multiple PRACH transmissions. Summary of change: Dropping rule of single PRACH is extended to multiple PRACH transmissions. Consequences if not approved: It may be not clear when applying existing dropping rule of single PRACH transmission to multiple PRACH transmissions. < Start of TP > 8.1 Random access preamble *** Unchanged parts are omitted *** For single cell operation or for operation with contiguous carrier aggregation in a same frequency band or for operation with non-contiguous carrier aggregation in a same frequency band if the UE is not provided with intraBandNC-PRACH-simulTx-r17, a UE - does not transmit PRACH and PUSCH/PUCCH/SRS in a same slot with respect to the smallest SCS configuration between the SCS configuration for the UL BWP with the PRACH and the SCS configuration for the UL BWP with the PUSCH/PUCCH/SRS transmissions, - does not transmit PRACH and
PUSCH/PUCCH/SRS when a first or last symbol of a PRACH transmission in a
first slot is separated by less than - for a PRACH
transmission with *** Unchanged parts are omitted *** |
Agreement
For multiple PRACH transmissions,
· Layer 1 notifies higher layers to suspend the corresponding power ramping counter when PRACH transmission in all of PRACH occasions are dropped.
· Layer 1 may notify higher layers to suspend the corresponding power ramping counter when PRACH transmission in any of PRACH occasions, but not all, is dropped or when PRACH transmission in any of PRACH occasions is with reduced transmit power.
Final summary in R1-2401554.
R1-2400039 Remaining issues on further NR coverage enhancements Spreadtrum Communications
R1-2400112 Maintenance of Rel-18 Coverage Enhancements Huawei, HiSilicon
R1-2400222 Maintenance on Further NR Coverage Enhancements vivo
R1-2400292 Maintenance of Rel-18 coverage enhancements ZTE
R1-2400368 Remaining issues on further NR coverage enhancement Intel Corporation
R1-2400411 Remaining issues on Rel-18 coverage enhancements CATT
R1-2400655 Remaining issues on PRACH coverage enhancement China Telecom
R1-2400706 Maintenance on Further NR Coverage Enhancements Samsung
R1-2400809 Remaining issues on further NR coverage enhancements Nokia, Nokia Shanghai Bell
R1-2400829 Maintenance on further NR coverage enhancements Panasonic
R1-2400925 Remaining issues on dynamic switching between DFT-S-OFDM and CP-OFDM InterDigital, Inc.
R1-2401076 Maintenance of Further NR Coverage Enhancements Ericsson
R1-2401094 Maintenance on Further NR Coverage Enhancements NTT DOCOMO, INC.
R1-2401248 Remaining issues on Rel-18 NR coverage enhancements LG Electronics
R1-2401420 Maintenance on Further NR Coverage Enhancements Qualcomm Incorporated
R1-2401504 Summary #1 on dynamic switching between DFT-S-OFDM and CP-OFDM Moderator (InterDigital)
Agreement
For the reporting of PCMAX,f,c for assumed PUSCH as agreed in RAN1#114, applicable PUSCH include: Any PUSCH
Agreement
Adopt the following TP to Section 7.7.1, TS 38.213.
· Reason for change: Introduce power headroom information for assumed PUSCH in TS38.213.
· Summary of changes: Description of the provision of Pcmax for an assumed PUSCH and associated conditions.
· Consequences if not approved: Specification does not support reporting of power headroom information for assumed PUSCH.
7.7.1 Type 1 PH report
<<< Start changes >>>
- a first Type 1 power headroom report and a first configured maximum output power associated with the first TCI-State or TCI-UL-State, and a second Type 1 power headroom report and a second configured maximum output power associated with the second TCI-State or TCI-UL-State, for an actual PUSCH transmission using a spatial domain filter corresponding to the first TCI-State or TCI-UL-State and using a spatial domain filter corresponding to the second TCI-State or TCI-UL-State.
If a UE provides a Type 1 power headroom report for an activated serving cell based on an actual PUSCH transmission, is provided assumedPUSCHInfo, and dynamicTransformPrecoderIndicationDCI-0-1 or dynamicTransformPrecoderIndicationDCI-0-2 is set to enabled for the active bandwidth part of the serving cell:
the UE provides 
based
on any applicable maximum output power reduction for an assumed PUSCH with
transform precoder enabled, if supported, if transform precoder is disabled for
the actual PUSCH; or based
on any applicable maximum output power reduction for an assumed PUSCH with
transform precoder disabled, if supported, if the transform precoder is enabled
for the actual PUSCH. All other parameters used for the
calculation of PCMAX,f,c(i) of the assumed
PUSCH are the same as the actual PUSCH.
<<< End changes >>>
Agreement
RAN1 draft an LS to inform RAN4 (with RAN2 in Cc) that RAN1 do not find any RAN1 specification impact to the UE capabilities powerBoostRel18 and powerBoostTSRel18 and that RAN1 expect RAN4 and RAN2 to develop the specifications for these UE features.
R1-2401626 [Draft] Reply LS on UE capabilities for MPR reduction Moderator (Nokia)
Decision: The draft LS R1-2401626 is endorsed in principle. Final LS is approved in R1-2401627.
Final summary in R1-2401505.
